ASP. NET Exception Handling

For Web applications, unexpected errors and exceptions are inevitable. We must provide error handling mechanisms for Web applications. When an error occurs, we must do two things: first, record the error information and send an email to the website maintenance personnel to facilitate the technical personnel to track and handle the error; second, an error is prompted on the end user page in a friendly way, rather than displaying unprocessed error information to the user.

 

Let's think about how many error handling mechanisms ASP. NET provides for us? If they are used at the same time, is there a certain priority ?. NET provides four error handling mechanisms, which have a certain priority order: page_error event> errorpage attribute> application_error event> <customerrors> configuration item. The following describes the usage of these four error handling mechanisms.

1. page_error event

The page_error event provides a method to capture page-level errors. You can only Display error messages (as shown in the following sample code), or record events or perform other operations.

Private void page_load (Object sender, system. eventargs E)

// Put user code to initialize the page here

Throw new exception ("Page error! ");

}

 

Protected void page_error (Object sender, eventargs e ){

Exception objerr = server. getlasterror (). getbaseexception ();

Response. Write ("error:" + objerr. Message );

Server. clearerror (); // pay attention to the use of this Code.

}

Note: This example displays detailed error information in the browser. This example is only for instructions. Be careful when displaying detailed information to end users of the application. A more appropriate way is to display a message to the user, tell the user that an error has occurred, and then record the detailed error information in the log.

2. errorpage attributes

You can set the errorpage attribute almost anytime on the page to determine which page will be redirected when an error occurs. To enable the errorpage attribute to play a role, the mode attribute in the <customerrors> configuration item must be set to "on ".

 

This. errorpage = "~ /Errorhandling/pageerror.html ";

If both page_error and errorpage exist, what is the page execution sequence when an exception is thrown? The page will first execute the page_error event processing function, if the page_error () event calls the function server. clearerror () clears the exception information and does not jump to the page specified by the errorpage attribute. If no server is called. clearerror (), exception information will continue to be thrown up, the page will jump to the errorpage specified page. This proves the priority order: page_error event> errorpage attribute.

 

3. application_error event

Similar to the page_error event, you can use the application_error event to capture errors that occur in the application. As events occur throughout the application, you can record application error messages or handle other possible application-level errors. Add the following code to the Global. asax file.

Protected void application_error (Object sender, eventargs E)

{Exception EX = server. getlasterror (). getbaseexception ();

// In actual application, exception information can be recorded or saved to the database.

// You can also send an error email to the website maintenance personnel.

Response. Write ("error:" + ex. Message );

// Clear the exception and avoid passing it to the upper-level for processing.

// The upper level is the <mermererrors> Configuration section.

Server. clearerror ();

}

4. <customerrors> configuration item

In the <customerrors> Configuration section of the configuration file web. config, you can specify the redirection page as the default error page defaultredirect or specify a specific page based on the HTTP Error code. If an error is not captured at any level before the application, this custom page is displayed.

 

<Customerrors mode = "on" defaultredirect = "~ /Errorhandling/applicationerror.html ">

<Error statuscode = "404" Redirect = "~ /Errorhandling/404.html "/>

</Customerrors>

Similarly, if application_error and <customererrors> both exist, there are also execution sequence problems. Because the priority application_error event> <customerrors> configuration item, when an application-level error occurs, the code in the application_error event is preferentially executed. If the application_error event calls server. clearerror () function. defaultredirect in the <customererrors> Configuration section does not work because the exception has been cleared. If the application_error event does not call server. clearerror () function. The error page locates the URL specified by defaultredict and displays error-friendly information.

By analyzing the above four error handling mechanisms provided by. net, we can classify them from different perspectives for our understanding and use.

1. functional Classification: handling exceptions are page_error events and application_error events. User error page redirection (redirecting the user to an error page) is the errorpage attribute and <customerrors> configuration item. 2. scope classification of error handling: page_error events and errorpage attributes are used for page-level error handling; application level) errors are handled by application_error events and <customerrors> configuration items.