Properly written Java software uses checked exceptions to indicate environmental problems external to the program such as an I/O error and uses runtime exceptions to indicate problems inside the program itself, in other words bugs. Every time a run-time exception is thrown there’s a bug somewhere. Sometimes the bug is inside the method that throws the exception. Sometimes the bug is in the method that invokes the method that throws the exception. Sometimes the bug is in a third-party library. Sometimes the bug is that someone is trying to do something in a place where they’re not allowed to do it, for instance open files inside a compare method. But make no mistake: if a run-time exception is thrown, there’s a bug somewhere.

We have not yet learned how to write perfectly bug free software. I suspect we never will. Defense in depth suggests that it’s a good idea to have a try–catch block near the top of your application — for instance in the main method or in the run method — that will catch any runtime exceptions you weren’t expecting, log them, and perform any cleanup it reasonably can. However, this is not enough. It is also necessary that someone carefully read the logs and fix the bugs that caused the runtime exceptions in the first place. Otherwise, you might as well not be logging them in the first place.

A disturbing number of third-party libraries have started using runtime exceptions where they shouldn’t be. In particular, they’re using runtime exceptions to report errors communicating with external services such as databases and DNS servers. (Yes I’m talking to you Hibernate). If you’re using such a library — although I recommend you don’t — then you will find a lot of these exceptions in your logs. In this case, the logs are warning you that you’re missing a catch block deeper inside the code. It’s annoying that you find this out at run time rather than at compile time as you could have if the library had used the right kind of exception in the first place, but better late than never.

One thing you should not do is include checked exceptions in the same log as the runtime exceptions. They mean different things and they require different responses. Most checked exceptions indicate environmental problems that take care of themselves. Database connection errors are one frequent example. In fact, any network service is simply going to fail some of the time. That’s just how TCP/IP works. Unless it’s failing all the time or very frequently, it’s not worth worrying about. You don’t want to clutter up your logs with a lot of detail you’re not going to do anything about. Limit the error logs to the problems you actually need to resolve, and every runtime exception that is thrown is a real problem that you actually need to resolve.

Here’s another way of thinking about it: a problem you’re just going to catch and ignore should be a checked exception. No runtime exception should ever be ignored. Runtime exceptions should be subjected to postmortems and fixed in the code so they cannot reoccur. Architect your code so that runtime exceptions are logically impossible.

Of course, not all checked exceptions should be ignored. Many of them indicate serious problems that require handlers to deal with. But if an exception can sometimes be ignored, then that exception is a checked exception. Leaving a code path that is known to throw runtime exceptions in your program is leaving bugs in your program. Every uncaught runtime exception, every exception that bubbles up into your main loop unexpectedly is a bug, and it should be fixed.

This entry was posted on Thursday, March 6th, 2025 at 7:00 am and is filed under Java. You can follow any responses to this entry through the Atom feed. You can make a comment or trackback from your own site.

Every time the subject of checked versus runtime exceptions comes up, someone cites Bruce Eckel as an argument by authority. This is unfortunate, because, as much as I like and respect Bruce, he is out to sea on this one. Nor is it merely a matter of opinion. In this case, Bruce is factually incorrect. He believes things about checked exceptions that just aren’t true; and I think it’s time to lay his misconceptions to rest once and for all.

Let’s see exactly what Bruce’s mistake is. The following is an extended selection from Thinking in Java, 4th edition, pp. 490-491:

An exception-handling system is a trapdoor that allows your program to abandon execution of the normal sequence of statements. The trapdoors used when an “exceptional condition” occurs, such that normal execution is no longer possible or desirable. Exceptions represent conditions that the current method is unable to handle. The reason exception-handling systems were developed is because the approach of dealing with each possible error condition produced by each function call was too onerous, and programmers simply weren’t doing it. As a result, they were ignoring the errors. It’s worth observing that the issue of programmer convenience in handling errors was a prime motivation for exceptions in the first place.

One of the important guidelines in exception handling is “Don’t catch an exception unless you know what to do with it.” In fact, one of the important goals of exception handling is to move the error-handling code away from the point where the errors occur. This allows you to focus on what you want to accomplish in one section of your code, and how you’re going to deal with problems in a distinct separate section of your code. As a result, your mainline code is not cluttered with error-handling logic, and it’s much easier to understand and maintain. Exception handling also tends to reduce the amount of error-handling code, by allowing one handler to deal with many error sites.

Checked exceptions complicate the scenario a bit, because they force you to add catch clauses in places where you may not be ready to handle an error. This results in the “harmful if swallowed” problem:

try {
// ... to do something useful
} catch (ObligatoryException e) {} // Gulp!

Do you see the mistake? It’s a common one.

This entry was posted on Tuesday, April 20th, 2010 at 5:59 am and is filed under Programming. You can follow any responses to this entry through the Atom feed. You can make a comment or trackback from your own site.