Effective Exception Handling :: Intro
Exceptions are an invaluable mechanism to a developer - so why do we abuse them so much?
I believe exceptions are our future, handle them well and let them lead the way.
Yes, I love exceptions. As a programmer, it is important to accept that occasionally things will go wrong. We can sanitize user input and pick up a lot of errors before they occur, but there are some things that are either out of our control or we just haven't foreseen yet.
When things do invariably go wrong, you really can't go past something that:
- stops execution dead in its tracks
- lets us know exactly where the occurred and to some extent what transpired beforehand
- allows the program to cleanup gracefully, which is critical if you don't want open cursors, connections or file handles floating around
And all this will very little effort from the developer. No need to check whether a return value represents an error code, no checking of status flags. They are no substitute for trying to avoid the exception in the first place but are indispensable when all of our best efforts have failed.
So why do I get the feeling that many programmers, both experienced developers and graduates alike have an unnatural fear of exceptions? To them, an exception is at best an inconvenience, at worst something to be suppressed at all costs. That attitude results in the following code being written all too often:
Connection connection = null;
try {
connection = DriverManager.getConnection("jdbc:some-driver/some-database");
}
catch (Exception e) {
// phew, glad we stopped that one from running rampant!
System.out.println("oops, something broke");
}
// carry on as if nothing happened
Statement statement = connection.createStatement();
I consider this to be one of the worst examples of Code Crime. But what makes it so horribly wrong?
Well, let's pretend that the database was not available when the connection was being established.
The problem with the code above is you that will never be able to determine that this was
actually the cause.
Why? Because the initial error is devoured without mercy and the code continues on its merry
way, despite the fact that the connection object is uninitialized.
This will invariably lead to a NullPointerException when trying to create the
statement further down the track.
The people who write this sort of code usually come up with a number of reasons why they think it's a good thing:
- They were taught that exceptions must be handled. Isn't this what we're doing?
- An error message (of sorts) is being sent to
System.out, which might end up being the console or one of a number of server logs. Someone is always looking at these, right? - It doesn't cost that much extra effort to write code like this.
- If the client doesn't see any errors then everything is ok.
These reasons all seem to point to the one philosophy:
An exception must not reach the client, because then we have to admit that something went wrong.
It's a classic case of shooting the messenger. Really, the exception itself isn't the problem, but only an alarm telling us that something is wrong. Turning it off doesn't resolve the problem, but instead just hides it from view.
An anology I'm fond of is that of a Nuclear Reactor. Imagine a technician sitting at the control panel, making sure everything is running according to plan. He notices a flashing light that indicates an increase in core temperature. This is dangerous. So what does he do? What if he decides to take it upon himself to "handle" the situation. He turns off the alarm so that nobody else sees it, and writes a note saying "reactor core about to go into meltdown!" on a post-it note and sticks it to the desk. Hopefully someone will come along and notice it. Fantastic, the disaster has been handled!
That might seem a bit far fetched, so how about a more relatable example. Imagine an online share trading system that fails to notify the client that their transaction has failed. They click the "sell" button, and a blank screen returns - or even worse - a confirmation message that all is ok. The exception was trapped, and an error written to a log file somewhere, but the code continued. This is quote a common scenario when we catch exceptions and fail to do something appropriate with them.
Now would be a good time to explain how exceptions should be handled.