5.2 Debugging

5.3.1 Unhandled Exceptions

One of the most compelling aspects of working with the CLR is that even poorly written code is unlikely to cause your program to crash. Because all memory is accessed through references, array boundaries are maintained and checked on access, and direct pointers into memory are a thing of the past, ^[12] it is almost impossible to cause a program error by writing to the wrong block of memory. This is not to say, however, that programs are now guaranteed error-free, but that errors are recognized by the runtime and can be dealt with programmatically.

^[12] Note that it is still possible to use pointers in C# with code that is marked as "unsafe," and managed C++ still works directly with pointers. Code written with pointers is known as unverifiable code and can be prevented from running at all by imposing the appropriate Code Access Security restriction. Most code written for ASP.NET applications will be verifiable C# or VB.NET code.

Whenever errors are detected by the runtime, such as a divide by zero or a failure to connect to a database, an exception is thrown. Ideally, your ASP.NET pages and components should trap any potential exceptions and decide what to do for recovery where the exception occurred. Often, however, programs do not check for all potential exceptions, so any unhandled exceptions propagate up the call stack to a top-level exception handler provided by ASP.NET. If you receive an unhandled exception when you are running on the server machine, ASP.NET will print a useful diagnostic message containing a stack trace and source code showing the location the error was generated. If your application is accessed remotely when an unhandled exception occurs, however, your clients will see an error page that looks like the one shown in Figure 5-7.

As a developer, you should be embarrassed if your clients ever see this page. Not only does it state that an unhandled error occurred on the server, but it gives advice on how to configure the application to avoid showing this page again. The second piece of advice given by this page is one you should always follow: Include a customErrors element in your configuration file that provides a redirection to your own internal error handling page so that clients never see this page. The only disadvantage to this solution is that you lose the exception information when ASP.NET redirects clients to the default error page you specify, so there is no way to log information about the error or to give clients information to pass along to you so that you can analyze what went wrong.

To deal with this lack of error information in your default redirection page, you can provide a handler for the Error event of the HttpApplication class. This event is issued whenever there is an unhandled exception, and it is called before the internal ASP.NET unhandled event code executes, giving you the chance to deal with the error yourself and perhaps not display an error page at all. To add a handler to this even, create a global.asax file, and define a function named Application_Error , as shown in Listing 5-5. By calling the ClearError() method of the HttpContext class, you can prevent ASP.NET's unhandled exception code from ever being executed. Be warned , however, that calling ClearError() also prevents any redirection to other error pages you may have defined for specific HTTP error codes.

Listing 5-5 Dealing with Unhandled Exceptions

<!-- global.asax -->
<%@ Application Language='VB' %>
<script runat=server>
Protected Sub Application_Error(src As Object, e As EventArgs)

  Dim ex As Exception = Server.GetLastError()
  ' do something with the error here, such as
  ' writing to the event log
  ' The following line writes the error message
  ' to the event log with a source of "MyApp"
  ' Note that the "MyApp" source must be preregistered
  EventLog.WriteEntry("MyApp", ex.Message, _
                      EventLogEntryType.Error)

  ' At this point you could call:
  ' Context.ClearError();
  ' to clear the error and continue execution.
  ' In general, you don't want to do this, because it will
  ' prevent ASP.NET from redirecting to your error pages
End Sub
</script>

The one other possible approach, which gives you the best of both worlds , is to look at the error in your Error handler, and if it is an unhandled exception, perform a Server.Transfer() to a custom error page you have built that displays information to users about the unhandled exception, which they could then relay to you. If it is any other type of error, just let it pass through, and ASP.NET will take care of redirecting users to the appropriate error page. It is important to perform the Server.Transfer() to the error page to retain the exception information, because performing a Server.Redirect() cause a round-trip back to the client, and the error information will be lost. Listing 5-6 shows the technique for performing the test on the exception and executing a transfer to the error page, and Listing 5-7 shows the sample error page that then has access to the exception information. Note that the exception typically is passed through the Inner Exception field of the Exception class.

Listing 5-6 Retaining Exception Information

' in global.asax
Protected Sub Application_Error(sender As Object, _
                                  e As EventArgs)

  Dim ex As Exception = Server.GetLastError()

  If ex.GetType() Is GetType(HttpUnhandledException) Then
    Server.Transfer("MyErrorPage.aspx")
  End If

  ' Otherwise, we fall through, and the normal ASP.NET
  ' error handling takes over
End Sub

Listing 5-7 Accessing Exception Information in an Error Page

<!-- MyErrorPage.aspx -->
<%@ Page Language='VB' %>
<html>
<h1>My error page</h1>
<%
Dim ex As Exception = Server.GetLastError()
    If Not ex Is Nothing Then
      Dim err As String = ""
      If Not ex.InnerException Is Nothing Then
           Response.Output.Write("The error was: {0}", _
                        ex.InnerException.Message)
  End If
End If
%>
</html>