Checked Exception

Whether checked exception is good or bad is such a big debate which is currently still not agreed upon. Do a google with the keywords “checked exception”, you’ll see a bunch of stuffs to read. I’ll do a quick summary on the key things which are usually used as arguments by the folks on the net

The Bad

It forces people to write code to deal with them (catch, throw) and in some cases it is so annoying that people tend to swallow them by an empty catch block
It makes (some) people think that their code is robust because the compiler forces them to remember about the exceptions
It causes problems in versioning. Say client A uses service B which has a method M which throws exception E1. A few month later you want to release a new version of B which is expected to have M throw a new kind of exception called E2. Now, A (and any other clients of B) cannot use the new version at all unless code of A, which calls M, has to be re-written to handle E2

The Good

It enables design by contract since the thrown exception is part of the public interface of the method
It is easier to write robust code with checked exception, given that you are not the kind of guys who like to swallow hard to eat stuff

While I am not a big fan of checked exception (i.e. I can happily program in C# and Ruby, which do not have the concept of checked exception), I am not against the concept (see more in the next paragraph) either. I do believe that checked exception can be highly valuable in certain kinds of applications (e.g. scientific applications) but not as much in others (e.g. business applications). The MS guys who work on the research Spec# (an extension of C#) should believe in the goodness of checked exception for introducing it into the language. On the other hand, a big catch-it-all block should be sufficient for many business and web applications.

And while I think there is value in the concept of checked exception, or any compiler enforcement of design by contract, I do think there can be better way of implementing that concept because the current Java implementation of checked exception does sometimes makes people to find “work around”, especially to the versioning issue mentioned above.

Now, a real world example. When I was working on my SCJD exam, one of the requirement was to provide an file-based implementation for an existing database interface (DB interface). The problem was that some file-based operations threw the (in)famous IOException, which was a checked exception, while the DB interface did not have declaration for it. There were two options for this. The first option was to wrap the IOException into a runtime exception and propagated it back to the client. The second option was to wrap the IOException as the inner exception of an exception declared in the DB interface. The second option could be very misleading due to the fact that the DB interface only threw very specific business exception such as DuplicateKeyException, and RecordNotFoundException etc. What if the client received a RecordNotFoundException just because an IOException was thrown (file was already locked etc.) while in fact the record did indeed exist? I did not accept such a bad design and chose option 1 instead, which had another problem: the client code not only had to handle the exceptions declared in the existing interface but also the “hidden” RuntimeIOException, which I think very awkward (though yet better than the other option).

Okay, let me summarize a few key points of this post

Checked exception, as like any design by contract enforcement, is a good concept. The problem, if any, is the implementation
An not-good-enough implementation may encourage (or even enforce) people to find work-arounds, or even dispose the whole feature by not using it
Until language designers can come up with languages which meet the best of both worlds (static checking while not getting into the way of developers), we need to live with it and try not to be “sloppy”
(Finally, something is not mentioned in the post and will possibly be the topic of another post: no compiler checking mechanism can take over the place of good unit test suites)