Global Exception Handling
- Implementing the Application_Error Event Handler
- Setting Up the Custom Error Page
- About This Article
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.