36   Report All Exceptions

“Protect your caller from weird exceptions. It’s your job to handle it. Wrap everything you call, and send your own exception up instead—or just swallow it.”

Part of any programming job is to think through how things should work. But it’s much more profitable to think about what happens when things don’t work—when things don’t go as planned.

Perhaps you’re calling some code that might throw an exception; in your own code you can try to handle and recover from that failure. It’s great if you can recover and continue with the processing without your user being aware of any problem. If you can’t recover, it’s great to let the user of your code know exactly what went wrong.

But that doesn’t always happen. Venkat found himself quite frustrated with a popular open-source library (which will remain unnamed here). When he invoked a method that was supposed to create an object, he received a null reference instead. The code was small, isolated, and simple enough, so not a whole lot could’ve been messed up at the code level. Still, he had no clue what went wrong.

Fortunately it was open source, so he downloaded the source code and examined the method in question. It in turn called another method, and that method determined that some necessary components were missing on his system. This low-level method threw an exception containing information to that effect. Unfortunately, the top-level method quietly suppressed that exception with an empty catch block and returned a null instead. The code Venkat had written had no way of knowing what had happened; only by reading the library code could he understand the problem and finally get the missing component installed.

Checked exceptions, such as those in Java, force you to catch or propagate exceptions. Unfortunately, some developers, maybe temporarily, catch and ignore exceptions just to keep the compiler from complaining. This is dangerous—temporary fixes are often forgotten and end up in production code. You must handle all exceptions and recover from the failures if you can. If you can’t handle it yourself, propagate it to your method’s caller so it can take a stab at handling it (or gracefully communicate the information about the problem to users; see ​Provide Useful Error Messages​).

Sounds pretty obvious, doesn’t it? Well, maybe it’s not as obvious as you think. A story in the news not long ago talked about a major failure of a large airline reservations system. The system crashed, grounding airplanes, stranding thousands of passengers, and snarling the entire air transportation system for days. The cause? A single unchecked SQL exception in an application server.

Maybe you’d enjoy the fame of being mentioned on CNN, but probably not like that.

Handle or propagate all exceptions. Don’t suppress them, even temporarily. Write your code with the expectation that things will fail.

What It Feels Like

You feel you can rely on getting an exception when something bad happens. There are no empty exception handlers.

Keeping Your Balance

• Determining who is responsible for handling an exception is part of design.

• Not all situations are exceptional.

• Report an exception that has meaning in the context of this code. A NullPointerException is pretty but just as useless as the null object described earlier.

• If the code writes a running debug log, issue a log message when an exception is caught or thrown; this will make tracking them down much easier.

• Checked exceptions can be onerous to work with. No one wants to call a method that throws thirty-one different checked exceptions. That’s a design error: fix it, don’t patch over it.

• Propagate what you can’t handle.