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


  1. I’d have to say checked exceptions, in practice, cause more problems than they are worth. The “worst case scenario” you show there is precisely why I don’t like checked exceptions. That code is more common than it should be and sometimes results in quiet failures. Also, another problem with that code is it will swallow runtime exceptions too, hence breaking the whole idea of runtime exceptions all because a developer is lazy. Once again this is in practice so you can blame the developer there I’ll give you that. If Java must have checked exceptions I would suggest making a checked exception superclass so developers can still be lazy without “clobbering” the idea of runtime exceptions; but that is still a compromise. I don’t see harm in removing checked exceptions because RuntimeExceptions can still be handled so all we are really losing is the “… eloquently documented…” exceptions. This documentation of exceptions causes a lot of extra code to be written and, in my experience, largely not handle the exception in any meaningful way other than directing a user to a “pretty failure” screen.

    Comment by Repete | May 24, 2007 | Reply

  2. I think we’re all just lazy in practice. I always intend to go back and “elegantly” handle the exception but my initial coding foray is always the “happy path” which leaves no room for exception handling. But then naturally the code gets deployed with a bunch of “printStackTrace()” messages (I *never* swallow and exception at least). It really gets bad if the method in question is a void, the caller has *no* idea that things failed. So at the *least* I will return false in those methods when I catch the exception. I think there are times when this is the correct response (if you’re the end of the line, and the caller of you isn’t expecting any exceptions, just true/false). But it’s not when there’s a complex chain of method calls and one of them selfishly takes the Exception and does nothing with it, providing no information to upstream callers.

    So I guess my point is that I agree with you Ken, but as with many developers, I find myself not elegantly doing the error checking and processing for non-trivial callstacks (especially relevant for GUI code). And I can’t claim to not have read a lot of articles similar to yours about the importance of them.

    Comment by Josh DeWald | May 24, 2007 | Reply

  3. Exceptions were a good idea!
    On paper. In reality, they are probably the most misused part of the Java language I’ve seen, and the biggest failure of java as a programming culture. Exceptions didn’t really work past the early revisions of java – as applications became more complex, error handling and exceptions became MUCH more complex. And no one really said “Hey, this wasn’t the greatest idea in practice, we need to rethink this” and deprecate exceptions.
    Now we have layers on top of, or in parallel to, exceptions that largely make the problems worse.

    In a real world app, you’re often better off reinventing the wheel and rolling your own error event handling.

    But hey, people also put objects in databases. *shakes head* .

    Arent we as engineers supposed to be making things simpler, not more complex?

    Comment by quellish | May 25, 2007 | Reply

  4. Thought you might find this of note:

    Comment by Josh DeWald | May 31, 2007 | Reply

  5. In response to the link Josh provided, Closures != Checked Exceptions, nor are they a suitable substitute. Egads, this would be a disaster.

    Comment by kriggio | May 31, 2007 | Reply

  6. This piece of writing is really a good one it helps
    new net people, who are wishing in favor of

    Comment by Greg Jacobs and Martin Crumlish Emperor Social | May 16, 2013 | Reply

  7. Hi there, all the time i used to check web site posts here in the early hours in
    the dawn, since i love to find out more and more.

    Comment by Accelerate High Growth Business Training | May 16, 2013 | Reply

  8. Somebody necessarily help to make critically posts I
    might state. That is the very first time I frequented your website page
    and so far? I amazed with the research you made to make this actual post extraordinary.
    Wonderful process!

    Comment by Lifestyle Liberation Blueprint Review | August 13, 2013 | Reply

  9. Best practice in exception-handling is summarized as “throw early, catch late”. Retries or other fault-tolerance should be at the highest possible level; retrying a connection to an external system, re-sending an entire outbound request, or rolling back & cleanly failing an incoming request.

    Conversely, it makes very little sense to retry sending individual bytes, or a single SQL query. Reliability & retry-handling generally make sense only at the “request” or “business” level.

    Checked exceptions were originally intended to highlight contingencies — predictable & recoverable outcomes, other than success — but were abused in the Java libraries to include all sorts of unrecoverable systemic failure.

    Unfortunately, the “declare or handle” requirement is directly opposed to correct “catch late” best practice, and results in vast numbers of do-nothing “catch-rethrow” blocks. The number & proportion of coding errors in these, is staggering..

    Using Hibernate, productivity is vastly greater than JDBC & nobody at all misses checked exceptions.

    Modern Java frameworks, influencers and now, lambda features in Java 8, are all moving on.

    Comment by Tom @ Literate Java | May 31, 2014 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: