• Choose a category
• All
• Classic-Fiction

By Root 5488 0

handler runs first, followed by the application handler. For this reason, if you have both handlers, you should avoid calling Server.ClearError in the page handler so that you do not compromise any of the following steps.

Logging Exceptions

In addition or in alternative to sending an e-mail message, you can decide to write an entry to the Windows event log when an exception is caught. Here’s the code:

void Application_Error(Object sender, EventArgs e)

{

// Obtain the URL of the request

var url = Request.Path;

// Obtain the Exception object describing the error

var exception = Server.GetLastError();

// Build the message --> [Error occurred. XXX at url]

var text = new StringBuilder("Error occurred. ");

text.Append(error.Message);

text.Append(" at ");

text.Append(url);

// Write to the Event Log

var log = new EventLog();

log.Source = "Your Log";

log.WriteEntry(text.ToString(), EventLogEntryType.Error);

}

The Event Log Source must exist prior to its use in an ASP.NET application—in this case, in the Application_Error method in global.asax. Typical ASP.NET account credentials are established such that the ASP.NET account does not have Event Log source creation rights. You’ll need to make sure the log is created first on each Web server your code will execute within prior to actually running your Web application.

Robust Error Handling

A good strategy for robust and effective ASP.NET error handling is based on the following three guidelines:

Anticipate problems by wrapping all blocks of code that might fail in try/catch/finally blocks. This alone doesn’t guarantee that no exceptions will ever show up, but at least you’ll correctly handle the most common ones.

Don’t leave any exceptions unhandled. By following this guideline, even if you did not anticipate a problem, at least users won’t see an exception page. You can do this both at the page and application levels. Needless to say, an application-level error handler takes precedence over page-level handlers. At the least, exceptions that are handled at the application level should be logged to feed reports and help the team to understand what went wrong and whether some bugs exist that need to be fixed.

Make sure that error pages don’t give away any sensitive information. If necessary, distinguish between local and remote users and show detailed messages only to the former. A local user is defined as the user that accesses the application from the Web server machine.

Outlined in this way, error handling is mostly a matter of writing the right code in the right place. However, ASP.NET provides developers with a built-in mechanism to automatically redirect users to error-specific pages. This mechanism is entirely declarative and can be controlled through the web.config file.

Mapping Errors to Pages

ASP.NET developers can also benefit from a declarative API to gain some control over the page being served to users after an unhandled exception. Such a declarative API relies on the information stored in the section of the application’s web.config file.

The Section

You turn on custom error messages for an ASP.NET application by acting on the section. Here’s an example:

...

The mode attribute specifies whether custom error pages are enabled, disabled, or shown only to remote clients. The attribute is required. When the mode attribute is set to RemoteOnly (the default setting), remote users receive a generic error page that informs them that something went wrong on the server. (See Figure 7-2.) Local users, on the other hand, receive pages that show lots of details about the ASP.NET error. (See Figure 7-1.)

The error-handling policy can be changed at will. In particular, ASP.NET can be instructed to display detailed pages to both local and remote users. To activate this functionality, you change the value of the mode attribute to Off. For obvious security reasons, Off should