Managing Adaptive Error Reporting in Mobile Web Applications

  • Article

During the processing of a managed-code Microsoft ASP.NET page, errors are thrown as exceptions and are handled by the ASP.NET error-handling mechanism.

This section provides a brief overview of error reporting in ASP.NET, and how this relates to ASP.NET mobile Web applications.

Overview of ASP.NET Error Reporting

Several types of errors can occur during a request, including the following:

  • Errors running a Web Forms page within ASP.NET, during the lifetime of the page.
  • Errors parsing a page, user control, or similar file while compiling it into an assembly.
  • Errors in the HTTP intrinsics, such as a request for a missing file.
  • Errors reading a configuration file.
  • System errors, such as an out-of-memory condition.

ASP.NET offers several features for customized error reporting.

Error-Reporting Mode

You can configure an application to show detailed errors with information relevant to the developer, basic errors for regular clients, or custom errors. You can adjust the settings to show only detailed errors when the client is the local computer.

Application-Level Errors

When an error occurs during a request, ASP.NET raises the error event of the application. An application-specific module can hook this event and override error-handling behavior.

Page-Level Errors

Errors occurring during the lifetime of a page cause the Error event for the page to be raised.   A handler for this event can perform notification tasks or attempt corrective action, including suppressing the error.

Custom Errors

In the web.config file, you can specify a set of custom pages for errors. When an error occurs, ASP.NET checks whether the application is configured to show custom errors, and whether an appropriate error page exists. If either of these is true, ASP.NET redirects to the error page, passing a parameter that contains the original URL.

Overview of Adaptive Error Reporting in Mobile Web Applications

Error reporting in mobile Web applications works the same way as it does in standard ASP.NET. The same customization techniques are available. However, three differences in behavior make error reporting in mobile Web applications more adaptive.

Device-specific Formatting

Error messages are automatically formatted to the target device's markup. For WML devices, this will be a card deck. For HTML devices, this will be a page of HTML.

Note   With error messages automatically formatted to the target device, it is recommended that you write custom error pages as ASP.NET mobile Web Forms pages, so that your custom error pages are properly formatted for each specific type of device.

Limited Default Error Message Content

For all mobile devices, the built-in error messages are terse in nature, even when the application is configured to show a detailed message. An error message typically contains the type of exception raised and the method that caused the exception. When the client is in a desktop browser, however, the standard error message is rendered.

HTTP Response Code

When ASP.NET reports an exception, it sets the HTTP response code accordingly. Browsers can act on the response code or show the error details contained in the response body. However, some mobile devices, particularly WML-based phones, show the response code only if there is an error. When an error occurs for such a device, the request returns a valid response code (200), with an error message contained in the body. On HTML devices, the request returns the real error code.

Adaptive Error Reporting Process

For mobile Web applications, ASP.NET finds and reports errors by using a six-step process that begins with the installation of the product and continues through delivering the error output:

  1. An HTTP module is installed into the standard application chain. This module, of class System.Web.Mobile.ErrorHandlerModule, installs an event handler for the application's error event.
  2. When an exception occurs at the page level during the page life cycle, ASP.NET calls the OnError method of the page. Because the page is a mobile page, an override implementation in the MobilePage is called, which in turn calls the HandleError method of the assigned page adapter. This adapter method can report the error in detail and return a value indicating that the error was handled. If it does not do so, the exception continues to be processed.
  3. ASP.NET automatically uses custom error pages.
  4. ASP.NET calls the error handler installed in step 1. If the target device is an HTML browser capable of rendering the full ASP.NET generated error message, this method returns.
  5. Otherwise, the event first collects information about the exception. Then, the event creates an instance of an internally defined mobile page of the class System.Web.Mobile.UI.MobileControls.ErrorFormatterPage, binds the data to the collected data, and renders the results. This page is responsible for producing a terse device-specific error message.
  6. Because the exception has been handled, the event does not return an HTTP error status code.

See Also

Application Developer's Guide | Developing ASP.NET Mobile Web Applications