Question

Suppose you’re designing an application (WebApp, Desktop, anything) and you need to define exception handling for the code. Since you want to make things reusable, what logic should you follow when handling exceptions? Are there any patterns to follow?

For example, if some DLL is going to use the network and the network is unreliable, then it may be wise to override the exception handler for that function to retry the request.

How does a developer approach handling exceptions for all the common aspects of development? Is there any pattern or template to follow?

When dealing with things such as Network, File, IO, Active Directory, and the Web, I’m sure there are a pre-set best practices on how to handle the most common and problematic issues today. Where are they located?

Answer 1

Throwing an exception should naturally only be done in an exceptional situation.

For handling, I would say that there are two circumstances when you want to catch an exception:

when there is a translation to be done

• To an error code
• To another exception
• To something the user can understand

at a module boundary

• Returning from COM calls, for example (into a non-exception-aware framework)
• Returning from a thread (there’s no-one to catch otherwise)
• Returned from a called-back function (because it’s unlikely the callback mechanism knows or cares about your exception.)

If you find yourself doing a try-catch-cleanup-rethrow kind of thing, use RAII instead and get rid of the try…catch entirely. Write your code so that, if an exception does occur, it acts in a sane manner. Look up the Abrahams Guarantees for details on what that entails.

---

An answer to MakerOfThings7 below, because it was too long for a comment.

By “Something the user can understand,” I mean for example a pop-up error message.

Imagine, if you will, the user clicks on a button on your application’s UI to go and retrieve some data. Your button click handler dispatches to some data storage interface. This interface could get the data from a memory stream, from a file, from a database. Who knows? In turn, these could fail, generating a MemoryStreamException, a FileException, or a DatabaseException. These might have been thrown 15 stack frames down and been correctly ignored by well-written exception-safe code that didn’t need to translate them.

The button click handler knows nothing of these, because there is an expanding army of data storage methods available to the data storage interface. So the data storage interface catches these exceptions, and translates them into a general purpose DataStorageException. This is thrown.

Then, the button click handler that called the data storage interface catches this exception, and has enough information to be able to display some kind of failure message to the user, translates the exception into some nicely formatted text and presents it.