I hate unchecked exceptions
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 :-/
Comments
Anonymous
August 12, 2004
Hi Cyrus,
I recon it doesn't need to be anything so grand. When I've written a function call I then go "Hey, I wonder what exceptions I've got to deal with?". If the function is listed in the online help then you can use that as a guide - but it doesn't list all the exceptions for that function. If it's not listed then you are stuck.
What would be useful is just a little window that listed all the exceptions thrown from a particular function. Click on the function to see the list.
Mind you, I guess once you have the code to grap this information for the IL/Metadata then it should be pretty trivial to insert it into the intellisense system. Type "catch (" and get a list of possible exceptions thrown. That would be cool.
Regards,
James.Anonymous
August 12, 2004
The comment has been removedAnonymous
August 12, 2004
James: Yup, that was definitely an application that we were considering in the IDE. Another was to warn you if you didn't catch an exception or declare that you threw it.
BTW: We do now show you the exceptions that the user documented his type with. Of course that puts the burden on the API developer to get those right (not that hard) and to maintain them (which can be very difficult). I've gotten many exceptions thrown that were never declared anywhere :(Anonymous
August 12, 2004
James: Yup, that was definitely an application that we were considering in the IDE. Another was to warn you if you didn't catch an exception or declare that you threw it.
BTW: We do now show you the exceptions that the user documented his type with. Of course that puts the burde n on the API developer to get those right (not that hard) and to maintain them (which can be very difficult). I've gotten many exceptions thrown that were never declared anywhere :(Anonymous
August 12, 2004
The comment has been removedAnonymous
August 12, 2004
Dr.Pizza: I thin kyou and I are in agreement here. As I explicitly stated, I dont' really hate unchecked exceptions, and I don't have enough experience to feel that checked exceptions are a suitable answer.
What I do know is that currently it's quite difficult to deal with the situation today and I'd like it to be better. because I don't feel checked exceptions are necessarily the right way to go (and i definitely don't feel taht i could get the change through the language and then possible enforced by the runtime (which is a good thing since, as you stated, there are so many issues with it)), i would like alternative ways to address the shortcomings of the current system.
I feel you're taking my one point out of context. I dont' mind that checked exceptions force you to annotate methods. Personally I feel that the exceptions thrown are part of the contract of a method and thus annotating them is not such a bad thing. That way if you do need to add an exception in the future it is a breaking change that your clients will know about. Nowadays it's far too easy for someone to make sure a change and to end up breaking clients unexpectedly (no pun intended). However, to be totally clear, that doesn't mean that I think checked exceptions are good, or the right way to go. I recognize the shortcomings, especially wrt interfaces. i would just like to see anything to help out here.
Note: "help" refers both to helping out the API consumer to let them know what to expect, and "help" refers to helping out the APi producer to help them maintain their documentationAnonymous
August 12, 2004
David++
:-)
Dr.Pizza: I want to add this:
I feel completely like a noob when it comes to error handling in programming. I don't feel like I do a godo job of i today and I consider the problem to be one I really need to work on. it's probably something I'll talk on later as I want to do a better job on it with the next project I work on.
As david said, one of the main problems is that the error path is usually not something that a lot of thought necessarily goes in to (probably due to programmer laziness) and that is pretty serious IMO.
If you have resources that I could look into to help with this I would very much appreciate hearing about them.Anonymous
August 12, 2004
How did I ever know that Mr. Bright would be replying to this topic..?Anonymous
August 12, 2004
Ding: Mr. Bright?Anonymous
August 12, 2004
The comment has been removedAnonymous
August 12, 2004
I often work with CommerceSevere and end up wondering what exceptions the CS objects will throw so that I can only catch those specific ones.
I don't think showing what the developer documented is really important, what would really help is to have an analysis tool in the IDE.
(Three days without posts, I thought you had gone on vacation or something ;)Anonymous
August 12, 2004
"Ding: Mr. Bright? "
Me.
Long-time checked exception hater, as anyone who reads the threads in Programmers' Symposium knows.Anonymous
August 13, 2004
The comment has been removedAnonymous
August 13, 2004
This is horrible of me, and I shouldn't even admit to it, but dang if most exception-handling stuff doesn't get a lot simpler without much real utility loss if you just catch/throw Exception in most cases, and only pay attention to subtypes if you have specific reason to believe it matters.Anonymous
August 13, 2004
James,
"What I really want is the ability to say "do this block if there's an exception, but don't actually catch the exception". try { whatever } on (Exception e) { log_some_info } - no catching, so the compiler has the same "who is throwing what?" data as if the try/on (or whatever word) block weren't there at all. "
As you state, you can rethrow the original exception, using throw; not throw e; There's another option beside this that may be more what you are looking for.
The CLR supports a fault block which provides almost exactly this functionality. It does not catch the exception and it only gets called if an exception has occurred. The fault block executes on the 2nd phase of the SEH mechanism, after all catch blocks have been examined to locate a handler and when finally and fault blocks run and the stack is getting unwound; it may not matter to you which phase it runs on but it's something to be aware of.
The bad news is that C# does not expose a syntax for this so you would have to write some IL to use this feature. Perhaps one day Cyrus will add support for this into C# :-) It does seem like it would be useful for logging/instrumentation purposes.Anonymous
August 16, 2004
James, I also like your suggestion about "do this block if there's an exception, but don't actually catch the exception". I wish it will be added to C# one day.
But now again about checked exceptions. I understand the above comments about why they aren't an ideal solution. Also, as I understand, an ideal solution was not found yet. All ideas about code analyzis done by IDE and/or compiler are not intended to work in 100% cases and I even think that they cannot work in pretty large percent of cases. What is the solution for virtual calls problem? For example, we use interfaces pretty much and this makes me think that code analisys won't help.
On another side, checked exceptions at least provide you a choice. You can either carefully fill in exception specifications or just declare your exceptions unchecked (or add "throws Exception" to every method). In my experience, with good development tools (like IntelliJ or Eclise are for Java) checked exceptions are rather helpful than harmful. Why not providing this feature in C#/CLR?Anonymous
August 23, 2004
I know this doesn't solve the whole problem, but I think it is a step in the right direction...
John Robbins writes in MSDN Mag on how to create an FxCop rule that detects methods that throw exceptions, but do not have an accompanying <exception> documentation comment.
http://msdn.microsoft.com/msdnmag/issues/04/09/Bugslayer/default.aspxAnonymous
August 24, 2004
The comment has been removedAnonymous
August 24, 2004
Oh, and not that you would, but please don't go through the documentation for every method in the framework and add a "this method might throw a ThreadAbortException", which is the logical conclusion of demanding to know what all exceptions can possibly occur.Anonymous
June 14, 2009
PingBack from http://patiocushionsource.info/story.php?id=2246Anonymous
June 16, 2009
PingBack from http://topalternativedating.info/story.php?id=11898