What circumstances should someone "try...catch"? Does this apply to libraries?

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

The general rule is capture generic exceptions and generate domain-specific exceptions. Also have a debugging mode for the API so you log every exception and you can debug it for future releases.

Of course this requires good debugging as you dont want to generate unrelated exceptions.

Just my two cents :).

Answer 2

Generally speaking:

1. Throw an exception for exceptional conditions.

2. Handle an exception if it makes sense to do so. If you can't handle the exception, allow it to migrate up the call stack.

The documentation for frameworks such as .NET usually describe the exceptions that can be thrown for a particular method call.

Answer 3

You answered your own question. Anywhere that there is a possibility of an error occurring that is out of the control/scope of your application, it's wise to place error handling around. You can never have too much error handling. Just ensure you're not coding by exception.

Answer 4

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.

Answer 5

Exceptions are helpful when debugging. They should be avoided if possible, because you should know your control flow.