When applications display ASP.NET runtime error messages to the end user, the root cause of the problem is due to insufficient error handling within the application. To gain the most granular control over errors, ASP.NET page events should be wrapped in a try…catch block so that proper error handling can be performed. However, the runtime does not provide this by default, so it must be manually performed. Any time something must be done manually the potential exists for a human to forget. Fortunately there are other features provided by ASP.NET that can provide a higher level of control.

Note – While it is also possible to implement a custom IHttpModule to perform error handling, it is out of scope for this post.

The ASP.NET framework essentially adds three additional ways to perform error handling by using, page events, application events and custom error handling in the app.config file. The first of these three, page events, allows the developer to use the Page_Error event handler to process any unhandled exceptions by subscribing to the the Error event inherited from the System.Web.UI.TemplateControl class. This can be done on each page to allow for fine grained control over the error handling. However, as with any event, you must be sure to manually subscribe, or use the AutoEventWireup feature. Developers that use this method must also consider whether or not the error should be bubbled up to the application level. In order to prevent the propagation from happening the handler must make a call to Server.ClearError() once the exception is properly handled. Applications that use a custom base class for all pages can use this feature to catch all unhandled exceptions. However, since inheritance sometimes must be broken, ASP.NET provides a simpler way to do this.

The second error handling method provided by the ASP.NET framework, application events, performs nearly the same functionality as the page event handler. The difference is that the Application_Error will catch any unhandled exceptions within an application’s scope. This handler must subscribe to the System.Web.HttpApplication’s Error event in the application’s global.asax file. Note that the AutoEventWireup and the Server.ClearError() concerns from the Page_Error description above also apply to the Application_Error event handler. However, once the error is handled at the application level, it might be advisable to let the user know something happened so they can notify someone. If the Server.ClearError() method is not called then another feature of ASP.NET can be put to use.

The last handling method provided by the ASP.NET framework is the <customErrors /> element in the web.config file. This element allows for an application to specify a default page to go to when there is an unhandled exception by using the defaultRedirect attribute. Simply set the value of the attribute to a relative or fully qualified hyperlink that the application should use. In order for the application to use this page the value of the mode attribute must also be set to “On” or “RemoteOnly”. Setting the value to “RemoteOnly” allows a system administrator to log on to the machine where the error is occurring and allow the ASP.NET runtime error message to display in the browser. For development environments this value is often set to “Off” so that the developers can see the error messages that are occurring. This is extremely helpful when an application writes messages to the event log, but the developers don’t have the necessary privileges to view the event log. The customError element also allows a developer to tailor how various HTTP status codes are handled by nesting an <error/> element inside.

Copyright © Scott P. Rudy 2009 All Rights Reserved