You can't debug a problem if you don't know that it exists. After you take your web application live, you are no longer the only one who is using it (hopefully), so you need an effective plan to track exceptions when they occur while others are surfing your site. A great way to do this is to implement an exception handler at the application level. This will allow you to consolidate the logging and notification parts of your exception handling in one convenient place. As you'll see from the code examples that follow, your global exception handler can handle both specific exceptions that you trap in your code and generic unhandled exceptions.
After your global exception handler has done its work, you'll want to redirect the users of your website to a friendly page that tells them that something has gone wrong, and then provide them with customer support information as well as a link back to your web application's home page.
Implementing the Application_Error Event Handler
The HttpApplication class in the System.Web namespace implements an Error event handler. This should not be confused with the HttpApplicationState class, which contains the definition for the Application object that you use in a typical ASP.NET page. You can implement this event handler in the global.asax file as shown in Listings 1 and 2.
Listing 1: Application_Error Event Handler
<%@ Application Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<script language="C#" runat="server">
void Application_Error(object sender, EventArgs e)
{
//get reference to the source of the exception chain
Exception ex = Server.GetLastError().GetBaseException();
//log the details of the exception and page state to the
//Windows 2000 Event Log
EventLog.WriteEntry("Test Web",
"MESSAGE: " + ex.Message +
"\nSOURCE: " + ex.Source +
"\nFORM: " + Request.Form.ToString() +
"\nQUERYSTRING: " + Request.QueryString.ToString() +
"\nTARGETSITE: " + ex.TargetSite +
"\nSTACKTRACE: " + ex.StackTrace,
EventLogEntryType.Error);
//Insert optional email notification here...
}
</script>
Listing 2: Application_Error Event Handler (VB)
<%@ Application Language="VB" %>
<%@ Import Namespace="System.Diagnostics" %>
<script language="VB" runat="server">
Sub Application_Error(sender As Object, e As EventArgs)
'get reference to the source of the exception chain
Dim ex As Exception = Server.GetLastError().GetBaseException()
'log the details of the exception and page state to the
'Windows 2000 Event Log
EventLog.WriteEntry("Test Web", _
"MESSAGE: " & ex.Message & _
"\nSOURCE: " & ex.Source & _
"\nFORM: " & Request.Form.ToString() & _
"\nQUERYSTRING: " & Request.QueryString.ToString() & _
"\nTARGETSITE: " & ex.TargetSite & _
"\nSTACKTRACE: " & ex.StackTrace, _
EventLogEntryType.Error)
'Insert optional email notification here...
End Sub
</script>
First, you have to be sure to set a reference to the System.Diagnostics namespace. You'll use the EventLog class in this namespace to write exception details to the Windows 2000 event log. Inside the Application_Error event handler, you declare an Exception object and initialize it through a call to Server.GetLastError().GetBaseException().
The GetLastError() method of the Server object simply returns a reference to a generic HttpException. This is a wrapper that was placed around the original exception when it was passed from your ASP.NET page to the Application_Error event. To get access to the original exception, you need to call its GetBaseException() method. This will yield the original exception information, regardless of how many layers have been added to the exception tree.
Next, you make a call to the WriteEntry() method of the EventLog class. There are several overloaded signatures for this method. The implementation that we chose to use here accepts three parameters. The first parameter is the source of the error. It appears in the Source field of the Windows 2000 event log viewer. The second parameter is the log data itself. You can see that we have added a lot of information to help track down what caused the exception, including the exception message, the exception source, the contents of the Form collection, the contents of the QueryString collection, the name of the method that generated the error (TargetSite), and a complete stack trace.
Note that the stack trace contains the name of the file that was the source of the exception. However, it strips off the contents of the query string—hence the need to specifically include it previously. The third and final parameter to the WriteEntry() method is an enumeration of type EventLogEntryType. We chose to use the Error element of the enumeration.
At the end of the event handler, we inserted a comment block where you can optionally put code to email the exception information to your IT support staff. Discussion of the different messaging paradigms in the .NET framework is beyond the scope of this article.
After the Application_Error event has completed its work, it automatically redirects the user of your web application to your custom error page. Optionally, however, you can use the Server.ClearError() method after you have logged the exception and redirect your user using the Server.Execute() method, specifying the page that you want to load in the user's browser.
The code that you have just implemented will capture all unhandled exceptions that occur in your web application. If you need to do some cleanup in the event of an exception and you implement structured exception handling inside your ASP.NET page, you can still leverage the global exception handler. Listings 3 and 4 present examples of how you would do it.
Listing 3: Throwing a Handled Exception
<%@ Page Language="C#" %>
<script language="C#" runat="server">
protected void button1_click(object sender, EventArgs e)
{
try
{
//do some complex stuff
//generate your fictional exception
int x = 1;
int y = 0;
int z = x / y;
}
catch(DivideByZeroException ex)
{
//put cleanup code here
throw(ex);
}
}
</script>
<form runat="server">
<asp:button id="button1" onclick="button1_click"
text="click me" runat="server" />
</form>
Listing 4: Throwing a Handled Exception (VB)
<%@ Page Language="VB" %>
<script language="VB" runat="server">
Protected Sub button1_click(sender As Object, e As EventArgs)
Try
'do some complex stuff
'generate your fictional exception
Dim x As Integer = 1
Dim y As Integer = 0
Dim z As Integer = x / y
Catch ex As DivideByZeroException
'put cleanup code here
Throw(ex)
End Try
End Sub
</script>
<form runat="server">
<asp:button id="button1" onclick="button1_click"
text="click me" runat="server" />
</form>
The code in these listings defines a web form with a text box and a button. When you click the button, it fires the button1_click event handler. In the event handler, you would do processing as usual. For the purposes of this demonstration, however, you intentionally generate a DivideByZeroException. This takes you to the catch block. Here, you can perform any page-specific cleanup code before calling throw(ex) to pass your exception to the global exception handler to be logged to the Windows 2000 event log.
When the global exception handler is finished logging the error, the defaultredirect attribute that you set in your config.web file (discussed in the next section) takes over, and you are redirected to the error.aspx page to display your friendly message to the user of your web application.
Setting Up the Custom Error Page
The first step in setting up a custom error page is to modify your config.web file to route the users of your web application to a friendly error page if an exception occurs. It helps to boost users' confidence in your site when it can recover gracefully from the unexpected. Add the code in Listing 5 to the config.web file of your web application.
Listing 5: Adding the <customerrors> Tag to Your Config.web File
<configuration>
<customerrors mode="On" defaultredirect="error.aspx" />
</configuration>
Note that your config.web file might already have a <customerrors> tag, so you might only need to modify the existing one. The mode attribute of the <customerrors> tag has three settings: On, Off, and RemoteOnly. If the mode is On, users will always be redirected to the custom error page specified by the defaultredirect attribute if an unhandled exception occurs. If the mode is Off, the details of any exception that occurs will be shown to the user in the browser. The RemoteOnly mode is a hybrid of the two other modes. If you are browsing your web application while sitting at the web server itself, it behaves like the Off mode. All other browsers of the site will get the behavior of the On mode. If no defaultredirect attribute is set, a default ASP.NET "friendly, yet not so friendly" message will be displayed to the user when exceptions occur.
Next, you need to build the custom error page (error.aspx) referenced in the config.web file. This is just an ordinary ASP.NET page that includes helpful information for the user of your web application if an error occurs. An extremely simple example is the one in Listing 6.
Listing 6: Simple Custom Error Page
<html>
<head>
<title>My web application: Error page</title>
</head>
<body>
An unexpected error occurred in the application. Please contact [ccc]
customer service at (800)555-5555. Or, you can click [ccc]
<a href="home.aspx">here</a> to go back to the homepage. [ccc]
Thank you for your patience.
</body>
</html>