Managed Exception Handling
Proper error handling is an essential part of good software design. Lucky for us, .NET provides excellent strongly-typed exception handling so that we need not rely on confusing and (ironically) error-prone return codes.
Attached is a very informative and concise presentation on exception handling in .NET written by Brad Abrams, lead program manager on the CLR team. I highly recommend reading it in your spare time.
Some of the main points to take home:
• Exceptions are not some incovenience that you should just shove aside - they are there for a very good reason.
• Plan your application's exception handling during the design phase as a part of the overall plan. Don't just tack on try...catch blocks at the last minute.
• Exceptions are better than return codes.
• If you're in a lower level of the application and you can't handle an exception in that context, let it bubble up.
• When you do catch an exception, don't just log and ignore it. Handle it.
• Empty catch blocks are unacceptable no matter what. Even when it makes sense to not do anything with an exception (e.g., in a composite pattern), the catch block should at least contain a comment explaining why the exception is not being handled.
• Avoid catching the base type Exception when possible at the top application level, and avoid entirely at lower levels.
• Catching specific exception types allows you, the top-level application developer, to better determine what to do when a runtime error occurs.
Discussion is encouraged!