Wierd - I just bumped into this blog entry from a customer about a day that I spent with them last year. Actually Alan has summarized my guidelines for exception handling in .NET (or any other environment for that matter) quite nicely, so I am going to cut and paste them in here. He must have a good memory because I didn't see him writing all of this down!
- Don't swalllow exceptions - ever.
- Don't use exceptions as return codes.
- By default, allow exceptions to bubble up the stack.
- Be careful of catching one exception type and re-throwing another:
- the only acceptable reason to do this is if you add contextual information to the original exception.
- Actually Mike raised a good point here – sometimes it is good to catch and re-throw a different exception at a subsystem boundary, but always do the next point.
- if you must do this - put the original exception into the inner exception.
- Implement a high-level exception filter to prevent raw exceptions reaching the user (both for security and usability).
- When throwing your own exceptions, always check if there is a system-defined exception type that is appropriate before implementing your own.
- Before rolling your own logging, assess the appropriateness of the existing logging support in the .NET Framework, Windows Management Instrumentation and the Enterprise Instrumentation Framework.
Another point that he didn't catch was that it is generally better to create a wide, flat exception hierarchy rather than a deeply nested one. Also remember that exceptions are relatively expensive things, so avoid throwing lots of them.