@others:

Ultimately, you can write stable and reliable code in any language, even assembly, even shell script. The question is: “How much work is it?” How hard is it to find and fix the 1000 hour bugs? To what degree does the language or its toolkit or libraries help prevent the introduction of bugs? What happens when you swap 3rd party components with a newer version or different implementation?

I lean on the side of “checked exceptions are a very good feature and have helped me write more robust code.” That said, I won’t argue that Java has a perfect implementation of them. When coding in Java vs C#, I have a *much* clearer picture of what can go wrong with a Java library, simply by examining the Exceptions that are thrown. I think that Anders’ argument about checked Exceptions not scaling is only true if you refuse to wrap checked Exceptions in other (checked or unchecked) Exceptions. Which is a silly choice to make. Wrapping exceptions is an essential part of maintaining an abstraction. You really don’t care, given an interface, that it can fail with this low level Exception or that one. But you do need to know which methods can fail by throwing an Exception. You will either know this because the language enforces it or through experience of the program failing when an uncaught exception is thrown. Which of those is preferable depends on many things, including the cost of failure, the cost of doing it right the first time, your unit test coverage, the documentation thoroughness of the 3rd party library, and so on.

Why have other languages not implement Java checked exceptions? I think the choice of everything being unchecked is inferior and lazier and yet much easier to choose. I think the better choice — superior to both — hasn’t been implemented in a language yet. Checked exceptions, IMHO, are the superior choice of those two choices, but they come with a lot of baggage in their current implementation and are maybe not appropriate to all choices. This is why there are so many different kinds of languages out there in common use.

Maybe what is needed is a method of automatically wrapping exceptions to match the current software layer, so a method could declare that any thrown exception that is not handled is automatically transformed into a different type appropriate to this layer of the abstraction. I agree with others who say, “Saying the *best* choice out of all options is that all exceptions are unchecked exceptions is like saying error checking code is not that important.” It is true that error checking code can add a big clutter to the code. But does that mean it’s better to go without it?

Those who say that it’s best to catch Exceptions only at the top event loop … clearly don’t work on big enough systems, or at least they work on systems where it’s always OK to throw away a bad event or request. There are certainly realms where that is true enough. It is most definitely not true everywhere. It does not strike me as a surprise that where Java succeeded was at the enterprise level, not at the desktop or web level. I commonly have a try/catch around main event loop as a precautionary measure. I also commonly install an “uncaught exception handler” that logs so that I will always know about uncaught exceptions in 3rd party code. But this is defensive programming, not the solution.

I think the ultimate solution to checked/unchecked will be found in some new language that will basically choose Java style checked + unchecked exceptions but with a significantly different twist, including a lot of syntactic sugar to solve the many valid points people have brought up about how annoying it can be to handle checked Exceptions. Things such as:

1) Automatic exception wrapping so exceptions you don’t want to handle can bubble up without being exposed as the base exception they are. If you are a security 3rd party library and you fail because your configuration caused you to throw a MalformedURLException, you want to throw a SecurityConfigurationException that wraps the other so the programmer making use of your library has a proper abstraction.
1a) Maybe something like try {} catch {} finally {} rethrows XXX where any Exception not explicitly caught is automatically wrapped as XXX, which can itself be checked or unchecked. Then you declare that this method throws XXX, and not whatever set of Exceptions could be wrapped by it, from that code block.
2) Interface versioning so you can change an interface, changing what Exceptions are or are not declared to be thrown, with ways of handling mismatching interface versions. Maybe automatic wrapping can solve this problem.
3) Perhaps the ability to mark a given Exception instance as checked or unchecked in a method’s declaration or code, so you can declaratively note whether something is expected to be caught or not. Maybe an annotation.
4) More things.

I disagree with many of Java’s choices with regards to what is a checked exception and what is not, and in both directions. I find, for example, that my code is more stable when I catch NumberFormatException, as this is almost always NOT a programming bug, but a bad input that needs to be handled. And I have found it appropriate in a very small number of places to catch Throwable, even if to log and rethrow, which as a general practice is not great but in the right place can provide invaluable information if you cannot depend on other software layers to report things appropriately. Also, “software should die on an Error being thrown” is not always true. If you get an out of memory error because the current request requires you to allocate an object that is too big to fit in memory, then you fail that request but don’t crash the program which is otherwise (in my experience) handling things just fine. It just got an invalid request. This depends on context and on whether or not one failed request means others can continue. How independent are the requests coming in? A programmer knows. An language runtime does not.

Here’s the Gosling interview: http://www.artima.com/intv/solidP.html It’s funny, in this same article, he pretty much covered everything that has just been discussed here. There’s nothing new here. Why do we have to keep having this same argument? Personally I blame it on Java not having come with clear enough instructions about how to use exceptions properly; the arguments and explanations appeared after usage in the wild was already all over the place, and the seeds of confusion implanted in the culture.

I agree with Squirrelsewer. Any code examples by Checked exception fans will be important for programmers to understand their point. Just repeating that programmers can handle errors and take alternate actions is not enough. Why so uncommon are the programmers taking alternate actions and what are they doing apart from logging or displaying error to the user?

I’ve come across a number of cases like this: the coder writes a line, the IDE underlines it with a red squiggle to tell the coder that an exception needs to be handled. Coder clicks on the helpful little lightbulb in the sidebar, IDE surrounds the code with try/catch and… bingo! The error goes away, but there’s nothing in the catch (maybe a log message if you’re lucky), and you have a swallowed exception.

If I had a pound/dollar/euro for every time I’ve seen that in the last couple of years, I’d be able to buy myself a reasonable lunch. At least with runtime exceptions people don’t try to catch them and they end up crashing something…

(Incidentally, does anyone know of any other languages that have implemented checked exceptions? I’d be interested to know…)

jt

So, for me writing programs is most pleasant with this 2-pass approach:
- first creating the prototype, no need to think about the exceptions and lot of other things
- and then create a Java program with exceptions properly declared.

I’ve been to Elliottes blog before and labored this point. I won’t spend so much effort here this time