Exception Handling in .net web apps

Question

I admit it: I don't bother with too much exception handling. I know I should do more but I can never wrap my head around where to start and where to stop. I'm not being lazy. Far from it. It's that I'm overwrought with exception handling ambivalence. It just seems that there is a seemingly infinite number of places in even the smallest app where exception handling can be applied and it can begin to feel like overkill.

I've gotten by with careful testing, validating, and silent prayer but this is a bad programming accident waiting to happen.

So, what are your exception handling best practices? In particular, where are the most obvious/critical places where exception handling should be applied and where are places where it should be considered?

Sorry for the vague the question but I really want to close the book on this once and for all.

Answer 1

Microsoft's Patterns & Practices team did a good job incorporating best practices of exception management into Enterprise Library Exception Handling Application Block

Event if wouldn't use Enterprise Library, I highly recommend you to read their documentation. P&P team describes common scenarios and best practices for exceptions handling.

To get you started I recommend read following articles:

• Exception Handling on MSDN
• Exception Management in .NET on MSDN
• Exception Handling Best Practices in .NET on CodeProject

ASP.NET specific articles:

• User Friendly ASP.NET Exception Handling
• Global Exception Handling with ASP.NET
• Exception handling in C# and ASP .Net

Answer 2

The golden rule with exception handling is:

"Only catch what you know how to handle"

I've seen too many try-catch blocks where the catch does nothing but rethrow the exception. This adds no value. Just because you call a method that has the potential to throw an exception doesn't mean you have to deal with the possible exception in the calling code. It is often perfectly acceptable to let exceptions propagate up the call stack to some other code that does know what to do. In some cases, it is valid to let exceptions propagate all the way up to the user interface layer then catch and display the message to the user. It might be that no code is best-placed to know how to handle the situation and the user must decide the course of action.