Managing Adaptive Error Reporting in ASP.NET Mobile Web Pages
During the processing of an ASP.NET page, errors are thrown as exceptions and are handled by the ASP.NET error-handling mechanism.
This section provides an overview of error reporting in ASP.NET and how this relates to ASP.NET applications that contain mobile Web pages.
Several types of errors can occur during a request, including the following:
Errors in the HTTP intrinsics, such as a request for a missing file.
Errors parsing a page, user control, or similar file while compiling it into an assembly.
Errors running a Web page within ASP.NET during the lifetime of the page.
Errors reading a configuration file.
System errors, such as an out-of-memory condition.
ASP.NET offers several features for customized error reporting.
You can configure an application to show detailed errors with information relevant to the developer, basic errors for ordinary users, or custom errors. You can adjust the settings to show detailed errors only when the client is the local computer.
When an error occurs during a request, ASP.NET raises the Application_Error event. A method in the Global.asax file can handle this event and override error-handling behavior.
Errors that occur during the lifetime of a page raise the Page_Error event. A handler for this event might be able to perform notification tasks or attempt corrective action, including suppressing the error, depending on the error.
In the Web.config file, you can specify a set of custom pages for exceptions that occur within the ASP.NET application. 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.
Error reporting in mobile Web pages works the same way as it does for any other ASP.NET applications. The same customization techniques are available. However, some differences in behavior make error reporting in mobile Web pages more adaptive to working with devices.
Error messages are automatically formatted to the target device's markup. For WML devices, this is a card deck. For HTML devices, this is an HTML page.
It is recommended that if you write custom error pages, you write them as ASP.NET mobile Web pages, so that your custom error pages are properly formatted for each 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 desktop browser, however, the standard error message is rendered.
HTTP Response Code
When ASP.NET reports an exception, it sets the HTTP response code to reflect the nature of the error. 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 the HTTP response code 200, indicating success, but the body of the page contains the error message. On HTML devices, the request returns the actual error code so the browser can respond accordingly.
For mobile Web pages, ASP.NET finds and reports errors using the following process:
If an application-level error occurs, an HTTP module of type ErrorHandlerModule handles the error. (This module is automatically installed.)
If 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. The 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. ASP.NET automatically uses custom error pages.
ASP.NET calls the error handler from step 1. If the target device is an HTML browser capable of rendering the full ASP.NET generated error message, the method ends.
Otherwise, ASP.NET collects information about the exception, creates an instance of an internally defined mobile page of type ErrorFormatterPage, binds the data to the collected data, and renders the results. This page is responsible for producing a device-specific error message. Because the exception has been handled, the event method does not return an HTTP error status code.