Sign in
Cyrus' Blather
Translate This Page
Translate this page
Powered by
Microsoft® Translator
Options
Blog Home
Email Blog Author
Share this
RSS for posts
Atom
RSS for comments
Search
Tags
No tags have been created or used yet.
Archive
Archives
November 2005
(1)
October 2005
(2)
September 2005
(11)
August 2005
(3)
July 2005
(5)
June 2005
(17)
May 2005
(8)
April 2005
(36)
March 2005
(30)
February 2005
(5)
January 2005
(7)
December 2004
(4)
November 2004
(5)
October 2004
(6)
September 2004
(16)
August 2004
(25)
July 2004
(35)
June 2004
(77)
May 2004
(73)
I hate unchecked exceptions
MSDN Blogs
>
Cyrus' Blather
>
I hate unchecked exceptions
I hate unchecked exceptions
CyrusN
13 Aug 2004 1:20 AM
Comments
22
Well, actually, I don't hate them at; i just hate not having any tools to tell me what exceptions could get thrown on the calls I make. Of course I realize how that might not be possible to compute given that you really don't know what could happen with a virtual call, however i still think a lot of useful information could be given. You could certainly start by marking any method that actually throws an exception (which escapes the method) with the information about that exception. You could then take the transitive closure to determine the extent that those exceptions could reach. You could use that information to make sure that the doc comments for methods didn't forget to mention those exception, and you could also use preexisting <exception> tags to augment the scanner for methods that could not be determined automatically.
I'm also not convinced of the problems that Anders' raises
here
. However, I don't have enough experience with large scale applications to know whether or not exceptions work well in those situations. I do know I've seen checked exceptions horribly abused (i.e. catches that, innapropriately, swallow exceptions. every methods decorated with "throws exception"). Of course, in the past I've stated that sometimes it's good to not have a features if its going to be abused and people have lambasted me for that. Now it appears I'm going to be hypocritical by saying that I think in this case we should have a feature even if it can be abused. However, i think that because it seems like it's so beneficial, and even if it's abused it's no worse than our current system. Of course, I do understand Anders when he says "Once a better solution is known—and trust me we continue to think about it—we can go back and actually put something in place. I'm a strong believer that if you don't have anything right to say, or anything that moves the art forward, then you'd better just be completely silent and neutral, as opposed to trying to lay out a framework." However, it's been a few years since the inception of C# and no perfect solution has been found, so maybe it's time for just something that makes things better.
I'd really like to work on something that could go and analyze existing code/metadata and garner this information for the user. I think it would be helpful and it would certainly be great for learning how to read and examine IL instead of just producing it. Of course... now I just have to find the time to do so :-/
22 Comments
Blog - Comment List MSDN TechNet
Comments
Loading...