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.

Answer 1

Well at the very basic level you should be handling the HttpApplication.Error event in the Global.asax file. This should log any exception that occurs to a single place so you can review the stack trace of the exception.

Apart from this basic level you should ideally be handling exceptions where you know you can recover from them - for example if you expect a file might be locked then handling the IOException and reporting the error back to the user would be a good idea.

Answer 2

Start off with a global exception handler such as http://code.google.com/p/elmah/.

Then the question comes down to what kind of application are you writting and what kind of user experience do you need to provide. The more rich the user experience the better exception handling you'll want to provide.

As an example consider a photo hosting site which has disk quotas, filesize limits, image dimension limits, etc. For each error you could simply return "An error has occured. Please try again". Or you could get into detailed error handling:

• "Your file is to large. Maximum filesizes is 5mb."
• "Your image is is to large. Maximum dimensions are 1200x1200."
• "Your album is full. Maximum storage capacity is 1gb".
• "There was an error with your upload. Our hampsters are unhappy. Please come back later."

etc. etc.

There is no one size fits all for exception handling.

Answer 3

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.

Answer 4

Might be more about exception handling in general than ASP.NET speific but:

• Try to catch exceptions as close to the cause as possible so that you can record (log) as much information about the exception as possible.
• Include some form of catch all, last resort exception handler at the entry points to your program. In ASP.NET this could be the Application level error handler.
• If you don't know how to "correctly" handle an exception let it bubble up to the catch all handler where you can treat it as an "unexpected" exception.
• Use the Try***** methods in .NET for things like accessing a Dictionary. This helps avoid major performance problems (exception handling is relatively slow) if you throw multiple exceptions in say a loop.
• Don't use exception handling to control normal logic of your program, e.g. exiting from a loop via a throw statement.

Answer 5

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 6

I recommend you start by adding a good error page that catches all exceptions and prints a slightly less unfriendly message to the user. Be sure to log all details available of the exception and revise that. Let the user know that you have done this, and give him a link back to a page that will (probably) work.

Now, use that log to detect where special exception handling should be put in place. Remember that there is no use in catching an exception unless you plan to do something with it. If you have the above page in place, there is no use in catching database exceptions individually on all db operations, unless you have some specific way to recover at that specific point.

Remember: The only thing worse than not catching exceptions, is catching them and not doing nothing. This will only hide the real problems.