• Choose a category
• All
• Classic-Fiction

Getting Information About the Exception

As mentioned, when you configure ASP.NET to redirect to a particular set of error pages, you lose any information about the internal exception that might have caused the error. Needless to say, no internal exception is involved in an HTTP 404 or HTTP 302 error. Unhandled exceptions are the typical cause of HTTP 500 internal errors. How do you make the page show context-sensitive information, at least to local users?

You get access to the exception in the Error event both at the page and application levels. One thing you can do is this: write a page-level error handler, capture the exception, and store the exception (or only the properties you’re interested in) to the session state. The default redirect will then retrieve any context information from the session state.

protected void Page_Error(object sender, EventArgs e)

{

// Captures the error and stores exception data

var exception = Server.GetLastError();

// Distinguish local and remote users

if (Request.UserHostAddress == "127.0.0.1")

Session["LastErrorMessage"] = exception.Message;

else

Session["LastErrorMessage"] = "Internal error.";

// Clear the error (if required)

Server.ClearError();

}

The preceding code checks the host address and stores exception-related information (limited to the message for simplicity) only for local users. The following code should be added to the Page_Load method of the page that handles the HTTP 500 error:

var msg = "No additional information available.";

var extraInfo = Session["LastErrorMessage"];

if (extraInfo != null)

msg = (string) extraInfo;

Session["LastErrorMessage"] = null;

// Update the UI here

ExtraInfo.InnerHtml = msg;

...

Writing context-sensitive error pages requires a page-level Error handler to cache the original exception. This means that you should write the same handler for every page that requires context-sensitive errors. You can either resort to a global error handler or write a new Page-derived class that incorporates the default Error handler. All the pages that require that functionality will derive their code file from this class instead of Page.

Error Reporting

Let’s put it down this way: fatal exceptions in software applications just happen. What do you do when such exceptions happen? Having some good exception-handling code is essential, but how would you collect any information related to the exception to study the case thoroughly?

Trapping and recovering from exceptions is only the first step, and it is largely insufficient in most cases. You need to figure out the section of the site that the user was visiting. You need to grab state information and the values currently stored in critical variables. Furthermore, you need to measure the frequency of the error to arrange a plan for bug fixing and maintenance. In a way, error reporting is the dark side of exception handling.

Features of an Error Reporting System

An effective error reporting system grabs error information and offers to report that in a variety of ways and stores. As you’ve seen, exceptions handled at the application level (that would otherwise go unhandled) should be logged and administrators should be notified.

What kind of information should be added to the log? At a minimum, the list includes values of local variables, the current call stack, and perhaps a screen shot of the failure. Is it sufficient to notify the webmaster of the failure? Although a notification is not a bad thing, an effective error reporting system reports exceptions to a centralized repository that is remotely accessible and groups them in some way—for example, by type.

Error Reporting Tools

Is such an error reporting system something you build from scratch once and adapt to any applications you write? Or is it an external framework you just plug into your solution?

In ASP.NET, there’s just one way to capture fatal exceptions—writing a handler for the Application_Error event. This can be done in two ways, however.

You can write code directly in the application