The original contents of this page were lost. The original idea may have been that exceptions should be caught in the lowest level context in which they could occur, and translated using ConvertExceptions.

From a DesignByContract perspective, the implementation of a given method is the method's responsibility, so implementation-related exceptions should generally not be let to escape that context. Exceptions emanating from an implementation choice should be either handled at the boundary responsible for the implementation choice, or translated into exceptions meaningful in client contexts.

Example: If you create abstractions for object persistence, then the database/corba/xml exceptions from the implementation shouldn't be let out of the persistence layer; use ConvertExceptions, HomogenizeExceptions, and RefineExceptions to provide exception types specific to the persistence layer and meaningful in client contexts.

Despite the above arguments, some consider it best to HandleExceptionsAsLateAsPossible.

See also ConvertExceptions, HomogenizeExceptions, RefineExceptions, ThrowDontCatch.

----

I sort-a feel if you can handle them early, they shouldn't be exceptions. -- DaveHarris

The issue of what should or not be an exception is completely orthogonal to the issue of when and where exceptions should be handled or ConvertExceptions applied. Once you determine that a piece of code may throw an exception, you have to decide what to do about it. HandlingExceptionsAsEarlyAsPossible says that they should be handled as close as possible because that is the best context to determine what to do with the exception: handle it and fix the error, catch it and ConvertExceptions, or let it through.

-- JuancoAnez

----

See also HandleErrorsInContext