The unhandled exceptions are those exceptions that are not caught in a try - catch block (inline coding) in an application. Whenever an unhandled exception occurs, ASP.NET displays its default error page to the user . The default error page can provide error details, along with code that can be a major security concern. You're usually better off displaying your own custom error messages instead. ASP.NET stops processing the Web page after it encounters an unhandled exception. However, you can trap an unhandled exception at an object level, such as Page or Application . Using Custom Error PagesASP.NET provides full built-in support for configuring custom error pages in a Web application. This configuration information is stored in an XML-based configuration file ( web.config ) where you use the <customErrors> element to configure custom error pages. The <customErrors> element consists of two attributes mode and defaultRedirect . The mode attribute specifies how the custom error pages should be displayed and can have one of the following three values:
The defaultRedirect attribute is an optional attribute that specifies the custom error page to be displayed when an error occurs. You can display either a static page, such as HTML, or a dynamic page, such as ASPX, as a custom error page. When the defaultRedirect attribute is not set to a custom error page, ASP.NET displays a generic error message in the browser. A specific custom error page can be displayed for a specific HTTP error code by associating the error code with the Web page through the <error> element. Multiple <error> elements can be nested inside the <customErrors> element. The <error> element consist of the following two attributes:
If an error occurs that has no specific page assigned through the <error> element, the custom error page specified by the defaultRedirect attribute of the <customErrors> element is displayed.
The following example shows how to set custom error pages for a Web application in the web.config file:
Using Error EventsWhen an unhandled exception occurs in a Web application, the following events are fired in successive order:
Both of these event handlers can be used to trap and work with unhandled exceptions. Using the Page.Erro EventThe Page_Error() event handler can be used to trap unhandled exceptions at a page level, like so: private void Page_Error(object sender, System.EventArgs e) { Response.Write("Error Details: <br>"); // Display error details. Get the last error on the Server Response.Write(Server.GetLastError().Message + "<br>"); Response.Write(Server.GetLastError().StackTrace + "<br>"); // Clear the error to flush the new response // and erase the default ASP.NET error page Server.ClearError(); } The preceding Page_Error() event handler displays the details of the unhandled exception. This is achieved by calling the HttpServerUtility object's GetLastError() method via the Server property. The method returns an Exception object that provides a reference to the last exception that occurred on the server. The ClearError() method of the HttpServerUtility object clears the last exception and does not fire subsequent error events (for example, Application.Error ) for the exception. For this reason, you will notice that the custom error page is not displayed even though an unhandled error exists. Also for the same reason, the default ASP.NET error page is not displayed if no custom error page is configured. Using the Application.Error EventYou can also choose to trap unhandled exceptions of the entire application in the Application.Error event. This event is handled by the Application_Error() event handler available in the ASP.NET application file, global.asax . Handling exceptions at the application level can be helpful when you want to take custom actions, such as logging the exception- related information in the event log for all Web pages, like so: protected void Application_Error(Object sender, EventArgs e) { // Get the Exception object wrapped in the InnerException property Exception unhandledException = (Exception)Server.GetLastError().InnerException; //If no event source exists, create an event source if(!EventLog.SourceExists("Mileage Efficiency Calculator")) EventLog.CreateEventSource("Mileage Efficiency Calculator", "Mileage Efficiency Calculator Log"); // Create an EventLog instance and assign its source. EventLog eventLog = new EventLog(); eventLog.Source = "Mileage Efficiency Calculator"; string type= unhandledException.Message; // Write an informational entry to the event log. eventLog.WriteEntry(unhandledException.Message); Response.Write("An exception occurred: " + "Created an entry in the event log."); Server.ClearError(); } When ASP.NET propagates the unhandled exception to the Application object (the Application.Error event), the Exception object is wrapped in an HttpUnhandledException object. Therefore, to access the exception at the application level, you must access the Exception object's InnerException property. If the Page_Error() event handler does not clear the unhandled exception through the ClearError() method, both the Page.Error and Application.Error events are fired. Further, if the Application_Error() event handler does not clear the exception, the error page (custom, if configured) is displayed in the browser. This happens because the error is not cleared although the event handlers for the Page.Error and Application.Error events are executed. |