Bees Are Social By Nature

Transcribed thoughts and experiences about computer programming.

Old News: Java Checked vs. Unchecked Exceptions

I know this is beating a dead horse, but I was recently part of a  discussion with a fellow developer that did not see the value of checked exceptions.  I realize my position is arguable, but I see checked exceptions as a valuable part of the Java language. Checked exceptions communicate to the implementor that the method being called may return with unexpected results and it is the implementors responsibility to deal with it appropriately.

I am a proponent of Programming By Contract for designing computer software.   Checked exceptions are an essentional part of this contract, especially when the method being called depends on the availability of an external system, such as a database, file system, network, etc.  The contract establishes that the “supplier” will operate perfectly in an ideal condition, yet should something unexpected happen that he cannot control, such as an intermittent network failure, then the “client” should be prepared to handle it accordingly, enabling some level of Fault Tolerance.  It could be argued that this information does not need to be forced or communicated within the code, yet I am personally very grateful that the contract can be so eloquently documented within the code.

A friend of mine argued that many of the Checked Exceptions in Java are really fatal errors and should be categorized as RuntimeExceptions.  While I am not willing to speak for all of the possible checked exceptions, some of the exceptions named were SQLException, IOException, and NamingException.  I argue that each of the above named exceptions are accurately identified as checked exceptions within Java.  An SQLException might just be describing a transient failure within the system and a robust system should degrade gracefully, reporting the error and alerting the relevant parties.  I would even go so far to say that a robust system should even self recover, should the issue with the external system correct itself, depending on the system requirements.  I am not going to qualify IOException and NamingException in this weblog entry, but the same sort of proper exception handling and reason for the handling applies.

I think effective exception handling is a lost art, or at least poorly utilized in much of the code I have read.  I can see why many developers may feel that checked exceptions are a waste, especially when I repeatedly see code that looks like

try { 
  // do something that can throw an exception. 
} catch (Exception e) {}

I must say this is a worst case scenario, but with the exception (wow a pun) of maybe adding a logging statement, it happens to be one of the most common errors I find in code using static analyzers, like FindBugs or PMD.

In his article, Effective Java Exceptions, Barry Ruzek does an excellent job at describing how a Java developer can make effective use of the Java exception model.  I realize he implies that in many cases IOException, and other checked exceptions, are often not recoverable, which differs, in part, from my position, yet his article captures the essense of how and why exceptions should be handled.  From his abstract:

One of the most important architectural decisions a Java developer can make is how to use the Java exception model. Java exceptions have been the subject of considerable debate in the community. Some have argued that checked exceptions in the Java language are an experiment that failed. [Barry Ruzek’s] article argues that the fault does not lie with the Java model, but with Java library designers who failed to acknowledge the two basic causes of method failure. It advocates a way of thinking about the nature of exceptional conditions and describes design patterns that will help your design. Finally, it discusses exception handling as a crosscutting concern in the Aspect Oriented Programming model. Java exceptions are a great benefit when they are used correctly. [Barry Ruzek’s] article will help you do that.

I am sure I haven’t even touched the surface on this topic, but I think there is enough here to start a decent discussion. 

May 24, 2007 Posted by | java, Programming, technology | 9 Comments