By Jonathan Goodyear, Brian Peek, and Brad Fox
This article is brought to you by New Riders Publishing, publishers of Debugging ASP.NET
The integration infrastructure consists of a set of middleware technologies that provide the interoperability services necessary to establish communication between applications. This provides the foundation on which we define the integration architecture.
Global Exception Handling
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>
About This Article
This article is excerpted from Debugging ASP.NET by Jonathan Goodyear, Brian Peek, and Brad Fox (New Riders Publishing
(http://www.newriders.com),
2001, ISBN 0-7357-1141-0). Refer to Chapter 4, "Code Structure That Eases
Debugging," for more detailed information on the material covered in this
article.
© Copyright New Riders Publishing, All Rights Reserved
# # #
