GreyWizard's Journal: Checked Out

[This is a bit of a mess for the moment. I've copied the text out of some debates I've engaged in on the [de]merits of checked exceptions before it falls of the end of Slashdot's 24 comment limit.]

Checked exceptions are bug not a feature. An exception is useful only because it allows a programmer to handle an error or unusual condition in the place on the stack that makes the most sense. Checked exceptions force every method on the stack to have some sort of boilerplate code to manage the exception even the only thing to do is pass it on up the stack. One might as well revert to returning error codes -- this will yield more efficient code too.

Worse, the entire concept breaks down when interfaces are involved. An interface can't predict what kinds of exceptions its implementations might want to throw, so there is no correct way to define them. Checked exceptions do more harm than good. Maybe that's why no language other than Java has adopted them.

First of all, checked exceptions are not the only, not the best and not even a particularly good way to get documentation about what exceptions might be thrown. Programmers can and often do declare "throws Exception" which completely defeats the purpose. An automated documentation tool like javadoc can and should enumerate the possible exceptions each method might throw.

Second, checked exceptions are an unacceptable burden on programmers for several reasons. They are a tedious obstacle to rapid prototyping, where a programmer cannot really know what exceptions are likely to be thrown and shouldn't be asked to enumerate them. You won't get a chance to write a server application that has to work 24/7 if you can't create an effective demo in time. Even when creating production code there is no reason to soak up programmer resources fighting pointless compiler errors. Some code simply should ignore exceptions, but checked exceptions don't allow that.

A good example of code that should ignore exceptions is interfaces. Checked exceptions make it impossible to correctly declare interfaces because there is no way a programmer can forsee every possible checked exception anyone might ever want to throw in an implementation class. Were all of this not true, why would Sun have officially enshrined swallowed exceptions in the JDK libraries with the "cause" method?

No other mainstream programming language has checked exceptions, and even languages that exist primarly to duplicate the good features of Java aren't adopting them. Why? Because they are a bad idea. It's that simple.

Client code can use "catch (Exception e)" and have some default behavior for dealing with unanticipated exception types. This is the correct thing to do, because it gives library implementations maximum flexibility while still permitting exceptions to be caught and handled specially where necessary. Many times the interface implementation is effectively a callback mechanism for the client code, so they belong to the same codebase and there is no question about what exceptions can be thrown.