Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

ASP.NET exception handling best practices

I'm looking for books, websites, or just advice on the best way to handle exceptions in an ASP.NET program.

Currently our application just throws the ugly red and yellow default screen at the user; exceptions are rarely, if ever, caught.  I'd like to have a standard exception handler which logs the exception to a log database (using log4net so we can configure whether logging is enabled or not with the web.config file on the server.

However, I'm still new to ASP.NET and I don't have the foggiest idea of how to go about making such a thing.  Okay, I lied, I have a few foggy ideas, gained from reading a few web tutorials, but I'm worried (certain!) that I'm missing something.

Thoughts, ideas, shoves in the right direction are most appreciated.  Thanks.

John.

John Wilson
Wednesday, May 26, 2004

Hi John,

In an ASP.NET application, you can deal with exceptions thrown by your assemblies at either the page level or the application level.

PAGE-LEVEL
------------------
For page-level error handling, you need to deal with the following:
1) Set the "customErrors" setting in Web.config
2) Add code to the page's Page_Error event to deal with the exception.
3) Create at least one custom error page.
4) Point your page's ErrorPage property to point to one of your custom error pages

First step is to decide how you're going to set the "customErrors setting in Web.config. If "Off", all clients, whether remote or local, receive the standard ASP.NET error page that "explains" the unhandled error. If "On", local clients see the custom error page that you've defined, whereas remote clients receive the standard ASP.NET error page. If "RemoteOnly", local clients see the standard ASP.NET error page, whereas remote clients see any custom error page that you've defined.

Normally you're likely to be developing your ASP.NET application locally. In this case, the setting you should use depends on whether you're testing your error handling. If you want to see the real exceptions, you should set
mode=RemoteOnly. If you want to test your custom error pages, you should set mode=On.

If you're developing your ASP.NET application on a remote server, you need to reverse these settings. So to see the real exceptions, you should set mode=On, and if you want to test your error handling, you should set mode=RemoteOnly. For a production server, you should always use the mode=RemoteOnly setting. This ensures that hackers don't see any detailed information that might be of use to them in the event of an unhandled error.
Instead, the only information displayed will be one of the custom error pages that you've defined.

Next step to deal with an exception that's bubbled-up to the page level is to add code to that page's Page_Error event. You can place any cleanup or logging code that you wish in this procedure. Note that if you *don't* want
to display a custom error page, you should use Server.ClearError  in this event to suppress the exception and then redirect your user back to one of your application's main pages after you've logged and dealt with the error.

Finally, set the Me.ErrorPage property to point to one of your custom error pages based on the error, or to your default custom error page.

APP-LEVEL
------------------
1) Set the "customErrors" setting in Web.config, as discussed above.
2) Set the "defaultRedirect" setting in Web.config to point to your custom
error page.
3) Create one or more custom error pages.
4) Add code to the app's Application_Error event in Global.asax to deal with the exception.

Add a defaultRedirect attribute to the customErrors setting. This attribute redirects any application-level exception to your default custom error page, in a similar fashion to the way that the ErrorPage property of a Web Form
contains a custom error page for redirecting page-level
exceptions.
<customErrors mode="On " defaultRedirect ="DefaultErrorPage.aspx " />

Then add code to the  Application_Error event procedure to do logging, cleanup, recovery and so on. After this code has executed, the exception is redirected for display to the page specified in the "defaultRedirect" attribute of the "customErrors" setting.

In addition to having a default error page for application-level exceptions, you can use the customErrors setting in Web.config to add a specific page redirection for each type of error.

<customErrors mode="On " defaultRedirect ="DefaultErrorPage.aspx " >
<error statusCode="403 " redirect ="/AccessForbidden.aspx " />
<error statusCode="404 " redirect ="/MissingPage.aspx " />
<error statusCode="500 " redirect ="/Support.aspx " />
</customErrors>

All of this is discussed in more detail in chapter 9 of my recent book - see link below.

HTH,

Mark
--
Author of "Comprehensive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128

Mark Pearce
Wednesday, May 26, 2004

I have an article that covers one method, and links to another.

http://www.dotnetdevs.com/articles/GlobalErrorHandling.aspx

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, May 26, 2004

See the Exception management section of this article

http://www.msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnpag/html/scalenetchapt06.asp

Ram
Thursday, May 27, 2004

*  Recent Topics

*  Fog Creek Home