Exception handling pattern

Question

It is a common pattern I see where the error codes associated with an exception are stored as Static final ints. when the exception is created to be thrown, it is constructed with one of these codes along with an error message. This results in the method that is going to catch it having to look at the code and then decide on a course of action.

The alternative seems to be- declare a class for EVERY exception error case (although related exceptions would derieve from a common base class )

Is there a middle ground ? what is the recommended method ?

Answer 1

To answer your specific question: Your decision should be based on how and why your exceptions will be processed. Do you want to make your program as foolproof as possible and conveniently react to every possible error scenario individually? Then you should indeed create an Exception class for every possible error cause you can identify. Otherwise, it is best to decide for each case individually.

There are a number of very common errors that jeopardize the stability of your entire program (such as ClassNotFoundException or NoSuchMethodException) - these should definitely be handled specifically. There are other errors that are closely related to one another, resulting in similar problems - these can very well be grouped or organized hierarchically (IOException stands for all kinds of errors related to in- or output, NetworkIOException stands only for in- and output errors related to network access, etc.).

Far more important than the exception's name and class hierarchy, in my opinion, is what you do with it: Where do you place your try/catch blocks? Which log entries should be written for which log file? Who should be notified? Which error messages should be presented only to admins/developers? Which errors should be communicated to the end user?

There are many patterns for handling exceptions, answering all sorts of questions like these. A quite extensive collection of common and useful patterns can be found here.

Answer 2

This is a good question. I believe there is definitely a middle ground.

Error codes are essential in my opinion for displaying errors to QA, and for customers to report to customer support and back to developers.

For programmatically handling errors I personally don't recommend error codes, I'd recommend a new Class for each category of errors, but definitely not for every single error. Java did a decent job getting us started with Exceptions like IOException, IllegalArgumentException, UnsupportedOperationException, etc. I frequently throw and catch these when appropriate in my code.

If you have a new category of exceptions that your code should respond to programmatically then you should definitely create a new class for it, extending the appropriate parent class. For example UserRegistrationException or ProductException.