Thoughts on (Un)checked Exceptions

Brian Goetz shares his thoughts on the (recurring) idea of removing checked exceptions from the Java language in a future version, because they tend to make code too ugly to read or are just considered a "failed experiment".

I personally count myself to the faction of people in favor of checked exceptions, because I believe they can certainly make people think more about error handling than they usually tend to. It may be harsh to say that, but in my opinion people - developers maybe even more - somethimes need to be forced to do unpleasant things. Of course checked exceptions can be a pain in the neck when you need to create e. g. Runnables, however in those cases you can still resort to throw an unchecked one . While this is a somewhat ugly technique you nevertheless are forced to think about error handling.

I suggest reading his proposals on what could be done to ease the symptoms. I mostly agree with the 2nd group of people and like the idea of having closures to better encapsulate all sorts of resource management hassles. Groovy has some nice examples of this, e. g. reading from a file and implicitly having all the boilerplate taken care of. To get some background on closures in Java, have look at the closures related posts on Neal Gafter's blog.

Concerning (checked) exceptions in general you might want to have a look (or better an ear) to an interview with Anders Hejlsberg - the principal mind behind Delphi and more recently .NET's C# language. You can find it in a series called "Thinking in Code" on Bruce Eckel's blog.


Popular posts from this blog

SAXParseException: -1:-1: Premature End Of File - Misleading error

Amiga 500 Restoration: A501 Memory Expansion

Something to know about Toshiba external USB HDD