Exceptional Exceptions

Exceptions

Exceptions and exception handling isn't something that should be difficult to do, and nor is it in Java. However the trouble with exception handling in Java is that no one can agree on a sensible method for handling them.

It is for this reason that I have written what I believe to be the most adequate way to handle exceptions, and the reasons for making these decisions.

I feel that the best way to get my point across is with some simple, all be it contrived examples. I am from this point on going to assume that anyone reading this document is familiar with the concept of a try..catch..finally block

Lets start with a bit of background, there are Throwables, checked exceptions, runtime exceptions and errors within java. The easiest way to categorise these and a some what glossy high level view is to say that every exception is a Throwable, so we shall ignore this semantic verb for now. A checked exception is an exception that a method may throw when it is called, by being a checked exception it gives the user of the API a sort of heads up letting them know that they should handle the exception in whatever would be the appropriate manner given the context in which the API was being used in. Then there are runtime exceptions, these aren't listed as possible outcomes of calling a method but they can be caught and dealt with if the API user believes it to be worthwhile, for example if the opportunity for an array to be incorrectly accessed is a possible outcome of a method being used then perhaps some programming logic can be put in place to mitigate the problem slightly, this sort of issue is usually an indication that a better design should be put in place so that, for example, an array is never incorrectly accessed. Then there are errors, it is true to say that these more often than not should never be caught as they tend to be things that are not recoverable such as OutOfMemory which means the status of the JVM can no longer be relied upon.

Good practice when designing an API means that the usage is examined from the perspective of a typical user, I prefer to use Use Cases to examine the problem from the users perspective. For anyone not familiar with this method it simply means putting together a story of the course of events of a user using the particular API call. The useful thing about use cases is that there is a specific section set aside for what should happen as an exceptional case which can then be related directly to the implementation of the solution.

Example

As an example lets imagine a simple system in a hotel lobby that is used to lookup the room that a person is staying in by using their name as the search criteria. The Use case might look something like;

1. type name of guest
2. hit search*
3. system displays the room number

Immediatley at point 2 we can think of an exceptional case, when the guest is not present in the hotel, this would result in an API that looked much like

public Integer getRoomForGuest( String guestName ) throws GuestNotFoundException;

Now behind the scenes the getRoomForGuest method may be accessing files, or a database or some other magical method of storing guest against room numbers, the point is that the user of the API shouldn't care about the fact that a FileNotFoundException or a SQLException may occur as this betrays the inner working of a method. Imagine the system is upgraded in the future from using a file system so that now it uses a database, if the API used to throw FileNotFoundException or IOException it would surely now have to throw a SQLException. Therefore through having a checked exception that is tighly coupled to the underlying implementation when the method implementation is altered the developer would have to alter every location where this method was called, and if the API was being used in another company their code may stop working which could result in them having to re-design/implement a new solution and this added cost could convince them to stop using your API. A friend raised the point that this could cause an exceptions true cause to be lost, I took it for granted that if anyone catches an exception they will as a matter of course add it to any exception being thrown as the "cause". Another point to raise here is that we should throw any exceptions that we really can't deal with. In the example above you could safely assume that an adequate response to not being able to find a person in the directory due to a FileNotFoundException or other IOException would be to say the person could not be found to the user. However many real life calls are not this simple, for example a with a different call it may be acceptable to inform a user of FileNotFoundException and other prescribed obviously solve-able exceptional cases but any other IOException that occurs should be considered more serious. In this case I would make the method call throw CallSpecificException (not the real name just an example) and IOException. The idea here is that the caller of our method would catch the specific exception and most likely tell the user but anything else would be dealt with differently most likely throwing to a higher authority in keeping with the idea of escalating exceptions that our caller can't directly deal with. Read on this idea should become clear.

I hear many people argue that we should not use checked exceptions instead make everything a runtime exception. I find this a little ...well...foolish, you see by having checked exceptions an API designer can give a hint to its user that here is something that could go wrong, or be out of the ordinary and you should think about how to handle it. The designer of the API is surely going to be more knowledgeable about the types of things that can go wrong during the operation of their code. If we were to replace these checked exceptions with runtime exceptions then the API user now has to either instinctively know what could possibly go wrong within someone elses code, which might be closed source and undocumented which means the only hint of what exceptions may occur is the method signature which now no longer has any mention of exceptions, this is why it seems a nonsense to turn everything into a RuntimeException.

Throwing and Catching

Another issue with exceptions seems to be when should they be caught and when should they be thrown, some people believe code should catch every Exception and some people believe you should catch nothing!!!Crazy surely we want to deal with exceptions that are pertinent to the code which has caused it and throw or escalate any exceptions that we weren't expecting and hence have no clear knowledge on how to recover from.

Lets look at the first option, catching every exception. By deciding that you want to catch every exception must mean that you intend to write code that can suitably handle every possible exception, that's fine until it isn't, that is to say in the typical mundane run of the mill processing, exceptions that you expect could happen are dealt with exactly as expected. However programs have a tendency to change like the shifting ice of the North sea, and with this change comes brand new exceptional cases that were not part of the original design. So where does this leave us? We are now catching an exception that we don't know what to do with, so our program responds by logging the problem and continuing as normal. The problem could be a simple one for example couldn't find a config file or something that any user should be able to rectify, or worse it could be a catastrophic failure that could be avoided if only the right people were notified, for example an upstream service has failed preventing a circular queue from being processed and thus will start to wrap around after X number of failed calls anyone handling a large throughput can understand just how serious a problem such as this can be. Many people still believe that the best, and sometimes only thing to do with exceptions is to log something exceptional occurred and continue. This denies the intent of exceptions they are not all meant to indicate that something went wrong in the program but merely that a path other than the norm should be pursued within the use case.

The next option is to catch nothing, i.e. throws Exception should be written at the end of each method signature. I see this as lazy coding, and not the good kind of lazy that leads a developer to automate repetative processes, but the bad kind of lazy that turns into a birds nest that someone else will have to unravell at a later date. The only thing this kind of coding goes to serve is to provide fodder to the WTF Blog. So should we never throw exceptions at all? Simple answer of course we should throw exceptions, but only when the design intends it to. Consider the throwing of an exception to be the escalation of an exceptional case, everything is being executed within the stack and the higher up this stack the more prevalent the process. What I mean by this is that in general the higher up the stack we get the more likely we are to want to shout about an exception happening, by thinking about this process it must surely seem obvious that if your code can't immediatley address the exceptional case occuring then it should let a higher authority know about it. Take the earlier queue underrun issue, you API deals with a small portion of the overall system that relies on the queue, your code doesn't know how to deal with this problem so it should escalate the issue by throwing it.

No one should see a Stack trace

This is both true and false, if no one was ever to see a stack trace there would be no need for them. In fact seeing a stack trace is very useful in solving the issue. I think this mantra has come about due to the fact that most developers are lazy when it comes to putting in simple handling code, we see it all the time an NPE occurs on some web server somewhere and the user gets shown a stack trace. The trace is useful to a developer (usually) but pointless to someone who is simply trying to buy something from the site. It is incredibly easy to redirect the user somewhere to say there has been a problem please bare with us while we try to fix it whilst at the same time sending the stack trace to someone that knows how to deal with it. The fact that this doesn't always get done is simply laziness.

...or at least only see a meaningful stack trace!

Not all developers were created equal, not all developers know how all parts of the systems they work with function, not all developers have the necessary skills to fix all problems a system can and will encounter during its normal operation. It is for this reason that 1st, 2nd and 3rd line support even exist. What might mean something to a 3rd line guru might as well be a foreign language to a 1st line and sometimes vice versa. By throwing specific checked exceptions at an appropriate level the correct trace can be sent to the person (or system) that can handle the exceptional case in the most appropriate manner. Working on large international systems it makes sense to have context sensative logging that will send stacks from a US system to the US support rather than to an Asian support desk or the user.

Conclusion

We all want to make systems that are good, that we can be proud of and say I don't think anyone could do a better job, it is for this reason that some forethought must be put into what exceptional cases are going to occur that I can deal with and anything my code can't deal with should be escalated. It is lazy to catch all exceptions with a catch (Exception... that simply logs what went wrong and continues.