异常处理模式

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

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.

Answer 2

If you can generalize the behavior across different error cases, especially if such behavior can be classified into "classes" of behavior (no pun intended), having an exception class hierarchy makes sense.

If you must catch EVERY (or almost) every exception anyway, and the handling of most of them is nearly identical (eg print error and quit), having 1 class with exception number in it makes sense as it's a simpler design.

Answer 3

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 4

The "middle ground", as I see it, is to use the internal "error codes" (common pattern, but not VERY common, IMO) as additional information for reporting/informational purposes; but not for deciding who catches the exception (this is determined by the exception class).