Catch What You Can Handle

Most of the time when a method can't do what it was originally intended to do, it must terminate. There are some methods, however, that can either choose a different course of action in the face of an error or allow the end user to choose a different course of action. These methods (or people) generally need some information about the error in order to make their decision. Exception propagation allows methods that can only terminate to defer error handling to those that can (directly or indirectly) make decisions by systematically terminating methods that can't make a decision and passing error data on to those that can. Methods that can handle errors tell the compiler that they can do so through the use of try/catch clauses.

Therefore: Include catch clauses only for errors that a method can actually handle. Ideally a catch clause should either try some other strategy to accomplish the method's goal or, more often, report the error to the end user and return the program to a passive state. Alternatively a catch clause may clean up resources and re-throw the exception (often there are better ways to do this see ResourceAcquisitionIsInitialization), or it can create and throw a new exception containing updated error information for the eventual handler (see ConvertExceptions). In all cases decisions are only made by decision making code.

-- PhilGoodwin

I HaveThisPattern. The only reason I ConvertExceptions is to add context information (typically holding the original as a NestedException in the new exception). -- JeffGrigg

This page seems complicated and unfocused.

I'm trying to figure out the distinction that the page is making.

I was referred to this page from:

http://www.python.org/cgi-bin/moinmoin/HandlingExceptions

The page argued like this: Do not write generic exception handlers. Write specific handlers. If you use generic handlers, you may respond to particular situations in inappropriate ways. For example, if you are expecting a division by zero, and you write a generic handler (rather than specific div-by-zero handler) that puts an "Infinity" value somewhere, then in the event of a Control-C (Interrupt Exception), your program will respond inappropriately. Thus, write specific handlers, not generic exception handlers.

Is that what this page means to say? Or is it some other distinction?

As it is, the first half of the page seems to be a complicated description of what ExceptionHandling is, and the second half seems to be recommendations on what to do with exceptions. But little seems to be about what you should catch or not catch. The page focuses on how to handle, not what to handle.

I do believe that the strategies listed on the page should be described. But I don't think that this is the page to talk about those things. I think those things should be discussed on other pages, and listed on the ExceptionPatterns page. The discussion on propagation should probably be in LetExceptionsPropagate.

-- LionKimbro

CategoryException