Exceptions and Tiers

I recently worked on a project where each tier had its own exception class - messy. To make things worse, each call between tiers was wrapped in a try-catch to translate it into the exception class of the calling tier. This made the code bloated and harder to read.

The only valid reason to catch and translate an exception is when you have additional important information to add. For example: converting a string to an integer can throw a library exception saying what happened, but only the calling function has enough information to tell which field failed. Of course if it's a programming error, the first exception is adequate as the stack trace will tell where it comes from. If, however, the data is from an untrusted source (user, XML stream, etc) - the user will require the field name and source. In this case the calling method will trap the conversion exception and add the additional information.

Exceptions can be divided into a limited set of groups.

1. Development Errors (aka bugs): Occur when the code fails because of faulty coding (or possibly design). It is hoped that all of these will be eliminated before a system goes to production. Realistically, a few will always hang around. In Java they are most commonly of type NullPointerException. Where they are explicitly created they should be unchecked exceptions since they need not be dealt with in the normal course of events. It's not uncommon for developers to throw these all the way back to the GUI as unsightly error pages. This isn't a good solution as the user loses their place and gets a very negative impression about the stability of the application. Equally unsuitably, some commercial applications just silently swallow these sorts of error - at best just logging them. While this is less scary for the user, it can often mean that they will not get the results they expect - and that the problem will never get dealt with. I've found that the best way of reporting them is to treat them as special validation messages. The user will see the form with a "sorry we seem to have a problem message" in one of the validation message fields. At least this way they can try for a work-around.
2. Validation Errors: At the other end of the exception are errors caused by the interface user. These can be as simple as a number out of range or as complex as not being able to kill the dragon because you forgot to pick up the fire wand 5 levels higher in the dungeon. From a development viewpoint the application should not break and the user should be informed of their fault in a clear, accurate and polite way. (Alas! We told you not to sell the 'Wand of Dragon Slaying'. But did you listen to us? No! The name of this game is Dragon Slayer, for Thor's sake.)
3. Internal Exceptions: Attempting to turn a string into a number with the Java Integer class can cause an exception if the string contains non-digits. You have 2 choices; either pre-parse the string or catch the exception and translate it into a validation. Most libraries will throw exceptions inappropriate for your application. Fortunately they are normally checked, so the compiler will nag you. Catch them as early as possible and translate them into either development error or validation exceptions - or deal with them if by some miracle that is possible. Do this in implementation layers and don't sully business logic with such confusing code.