Advanced exception handling in ASP.NET

Logging exceptions is crucial in ASP.NET applications. If you don’t have logging, who knows what could be going wrong with your application. Your users could be getting hundreds of errors without you even knowing if you don’t have popper logging set up in your application.

Most sites get the basics right for logging, but there are some circumstances which can easily be missed. For example, I worked on a site a couple of years ago, and we hadn’t quite got our error logging right. We also had an issue that during deploy time, thousands of error where being generated because we hadn’t configured the request queue limit correctly and because the app took a while to spin up, the queue would fill up and the site would error. We had no idea, and it wasn’t till we fixed the logging like I’ll describe here that we realized and where able to fix it.

The first place you’ll want error logging is in your Global.asax in the Application_OnError method. This method should be included when you create the Global.asax file. This method is called when any exception isn’t handled specifically within the code bubbles to the top of the stack. This the easiest way to start your logging, you just need to fill in the method with your error logging code.

Global.asax

namespace WebApplication
{
    public class Global : System.Web.HttpApplication
    {
        protected void Application_Error(object sender, EventArgs e)
        {
            Exception ex = Server.GetLastError();
            // Error handling code goes here
        }
    }
}

That works fine assuming two things: Firstly, your error logging code is correct, secondly, your applications DLLs are able to load correctly. What if they can’t? Then we take it to the next level of logging, configuring Web.Config to redirect to a page on error and than doing separate logging there.

At this level we’ll lose a little detail. Redirecting the error page loses the exception, but at least we know an error’s happening. We can also tell what page the error happened on and what HTTP status code was given out in the response. You’ll need to create a new file which handles the logging in it (in the Page_Load method for example,) though in order to get both file name and status code you’ll either need multiple error logging files or a rewrite rule using something like ISAPI_rewrite. The reason is that if you choose to include the status code in the query string the internal logic won’t automatically append the url to the query string, so the status code has to be part of the file name.

Web.Config

<?xml version="1.0"?>
<configuration>
  <system.web>
    <customErrors defaultRedirect="/ErrorUnkown.aspx">
      <error statusCode="404"  redirect="/Error404.aspx"/>
      <error statusCode="500"  redirect="/Error500.aspx"/>
      <!-- Etc. -->
    </customErrors>
  </system.web>
</configuration>

The previous method for logging while fail in a couple of scenarios. If the .NET run time fails to spin up at all due to configuration issues with IIS, or the Web.Config file becomes corrupt are just a couple of examples. The only way you can deal with this is by configuring IIS its self to deal with the issue. You can configure IIS to redirect the user to a different file if an error’s raised, since we’re assuming that the current website can’t be accessed we need to come up with something other than .NET to log the error. My solution was to use a Classic ASP file to log the error, because that should still work even if .NET is failing.

The first think you’ll need to do is create the Classic ASP file which logs errors to the correct location, which should be straight forward enough. Then you’ll need to configure IIS. In IIS 7 this is done through the error pages section, and once configured should look something like this:

IIS 7 Error Pages

I don’t have a sample screen shot for what it’ll look like in IIS 5/6, but Microsoft has provided a tutorial.

With all these measures in place, you should have a complete view of all errors you are generating on your site. Though you should also consider manually logging an error when you’ve caught the exception already and don’t want to display anything to the users.

You should also consider how you log your errors. You should try and log as much information as possible (cookies, query-string, form and all the headers in the request for example,) ideally into a place where it’ll be easy to generate reports from, somewhere like a SQL database is ideal.

Phil