The Joys and Sorrows of Exceptions

In my experience, the most serious bugs in programs in production are in error handling routines. Inventive programmers often try fancy things when dealing with errors, but error situations are often omitted during testing. This article examines the fundamental questions of exceptions: What causes exceptions, and what can be done with them?

Bad User, Bad Server, or Bad Programmer

Practices of an Agile Developer puts exceptional events into three categories:

• The user has done something wrong, like entered a numeric value in a non-numeric field, tried to access data which he's not authorized to see, entered a negative amount where a positive was required and so on. These types of errors are not exceptional at all but part of the normal course of events. Nevertheless, exceptions are often used to handle them, and sometimes, this is even a good idea. In Java Integer.parseIntNumberFormatException if given a non-numeric string and new URL(String) throws an InvalidURLException if it is given something that can not be parsed as a URL. These events may be the result of user error. throws
• Sometimes, a program depends upon things outside its control. Network and external servers are examples of this, as is the file system. No matter how good my code is, I can't stop people from knocking out the network cable. I call these kinds of exceptional situations system or resource exceptions.
• Lastly, try as I may, I never write perfectly correct programs. Occasionally, that pesky NullPointerException brings my program down like a house of cards. In this situation, all bets are off. I know that the program contains a bug, but I cannot safely assume anything about the nature of the bug.

Not all exceptions are cut and dry in what category they fall in. For example, a NumberFormatException is a configuration bug if it occurs while reading a configuration file, but a user error if it occurs while reading input data from a web form.

Dealing with Failure

The overall strategies for handling each of the exceptional situations above are very different. We should program to handle user errors and return pleasant and helpful error messages. However, when it comes to bugs, my recommendation is to get out of Dodge with as little fuzz as possible. The exact nature of the problem is by its very definition something we didn't think about. A NullPointerException should be handled at the topmost level, along with similar errors. The user should be informed that "we're terribly sorry, but despite our best, honest efforts, we have messed up. We'll try and fix it as soon as we can. For now, the best you can do it to try something slightly different and pray." Make sure that you don't corrupt data, however. All persistent data operations must be rolled back.