Via Ted Leung and Bill De HÓra, I read Ross Judson's comments on checked exceptions. This subject just keeps coming back...
I blogged about this half a year ago arguing against checked exceptions. In all honesty, I actually do like checked exceptions, but only when used in moderation. The problem is that the typical Java developer uses them to the extreme, making every custom exception checked, or doing things like what Ross suggests: making an exception hierarchy rooted in a LibraryException and then declaring their methods to throw LibraryException instead of the specific sub-class. What's wrong with that you may ask? read on...
In my opinion, checked exceptions should only be used in cases where
Use RuntimeException in all other cases.
Break these rules and you'll end up throwing too many exceptions that your caller will not know what to do with. And once that happens, developers that need to call your method will oftentimes either ignore your exception or just printStacktrace() it (which is just as bad as it provides no feedback to the user about what went wrong and does not change the application-flow - it does not actually handle the exception). Sometimes this is done under the assumption of "I'll come back later and properly handle this exception", but later typically never arrives.
The only way you can get your caller to properly handle your exceptions is if the exception type communicates excactly what the problem was, and your caller will know what to do when this problem occurs. This is rule #2, and can only be adhered to by throwing specific exceptions that tell the caller exactly what happened. This is what the problem is with declaring a method to throw a generic LibraryException - it doesn't tell the caller what went wrong so there's no intelligible way he can handle it.
When I interview people for a Java position, I oftentimes ask them the standard "what's the difference between a Exception and a RuntimeException?" question, followed by "when you create your own exception class, which do you inherit from when, and why?". 95% of the responses are "I always inherit from Exception".
This is why, even though I like the principle of checked exceptions, I have come to the conclusion that I like C#'s model better; Java's exception handling mechanism is simply abused way too often.
Surley the C# option is one of no choice.
Whereas at least with Java you can choose between inheriting from Exception and RuntimeException.
It must also be easy enough to enforce some rules around exceptions my having something that checks the code for the differing types.
I'm not sure how C# is meant to retrofit and better exception method later.
Yes, Java gives you the a choice that C# developers do not have, and freedom of choice is typically a good thing.
But when you deal with a developer pool whose majority still cannot get this right, you have to wonder if maybe it's not the developers, but the language design that is flawed.
I think you would agree that the absence of GOTO in most languages is a good thing as this is an easily abused code-construct. One could argue for GOTO though based on freedom-of-choice; after all, developers could choose whether they do or don't want to use a GOTO construct if this were available in the language.
Language designers have decided to not give the developers the choice of using GOTO as a means of protecting developers from themselves. I would argue the lack of checked exceptions in C# serves this same purpose.
Part of me wonders whether it's not the principle of checked exceptions, but the naming of the exception classes in Java that is at fault. When you need a custom exception-class, there is a natural inclination to inherit from a class called Exception. Maybe if Exception was unchecked and a CheckedException class existed, developers would have put some more thought into whether their exceptions needed to be checked or not, and err more on the side of unchecked exceptions when making the wrong choice.
OK. Lots of people get killed in cars. Let's outlaw them. The good received from people that don't abuse cars just don't outway the drunk drivers or other people that may kill people in cars.
Why are you so concerned that other people misuse checked exceptions. Some people misuse inheritence. Should we get rid of that?
Your logic makes no sense at all. I think your rules for using them is fine. If you want to completely quit using checked exceptions because some one might "misuse" them, I don't want to use your code. Fortunately, I probably won't have to!
You logic is flawed: only a very small percentage of people who drive cars get killed in the process. On the other hand a very large percentage of Java developers abuse checked exceptions.
On page 3 of this interview with Anders Hejlsberg, he describes what has been my experience as well in all large Java projects I have worked on:
In the large, checked exceptions become such an irritation that people completely circumvent the feature. They either say, "throws Exception" everywhere; or—and I can't tell you how many times I've seen this—they say, "try, da da da da da, catch curly curly." They think, "Oh I'll come back and deal with these empty catch clauses later," and then of course they never do. In those situations, checked exceptions have actually degraded the quality of the system in the large.
Personally, I am not quitting using checked exceptions in Java - they're there to stay so I try to use them whenever their use is called for. Usually it isn't and I use RuntimeException instead.
All I am saying is that I agree with Microsoft's decision not to include them in the language design for C#. While checked exceptions can have benefits when used sparingly, it's my experience that in the way the average Java developer uses them, they do more harm than good.
See also this post by Bruce "Thinking in Java" Eckel on the subject.
Posted by Luke Hutteman at September 5, 2003 10:31 AMalthough i wouldn't equate checked exceptions with GOTOs, i do agree that they are abused. moreover, a lot of the introductory java literature teaches that sort of abuse.
in his book "J2EE Design and Development" ( http://www.amazon.com/exec/obidos/ASIN/0764543857 ), rod johnson goes so far as to say, "checked exceptions are a failed experiment (paraphrased)." and then goes on to provide the same set of guidelines listed above on when to use checked exceptions. in the framework he provides with the book (which is now available at www.springframework.org), the majority of exceptions are derived from an unchecked hierarchy.
the problem is in the education. lots of tutorials, texts, and teachers telling people to derive their exceptions from Exception, giving examples and spreading the disease. kind of like the double-checked locking singleton pattern.
checked exceptions are a nice form of documentation but at the same time they get in the way of information hiding and clutter the code. if they removed checked exceptions, i wouldn't miss em.