. Net four error handling mechanisms

For a web application, errors are inevitable. Therefore, we should plan ahead to provide appropriate solutions for possible errors. In fact, a good error handling mechanism is an important criterion for measuring the quality of Web applications. Think about it. If the user accidentally enters the wrong URL in the browser or when the user provides some information that leads to a program error, if we do not handle the problem, instead, the stack information of 404 or 500 error pages or even errors is displayed in front of the user, which will undoubtedly scare some users away. Therefore, we should have a full understanding of the error handling mechanism when developing web applications.

Let's go back to ASP. NET and raise two questions for everyone to think about: ASP. NET provides several error handling mechanisms for us? If several error handling mechanisms are adopted at the same time, is there a certain priority between them? With this problem, let's take a look at our most common web. config file:

 

<? XML version = "1.0"?>
<Configuration>
<System. Web>
<Customerrors mode = "on" defaultredirect = "genericerrorpage.htm">
<Error statuscode = "403" Redirect = "error403.htm"/>
<Error statuscode = "404" Redirect = "error404.htm"/>
</Customerrors>
</System. Web>
</Configuration>

 

 

For the <customerrors> setting item, I don't need to talk about it any more. For details, refer to msdn. The first error handling mechanism-using the <customerrors> configuration item of Web. config should be the most commonly used.
Next, let's look at another commonly used file: Global. asax. What do you think of when talking about this file? Yes, it is the event related to the two web application objects (Application and session. Among these events, there is an error-related event in the application scope, and the corresponding event processing method is application_error. As the name suggests, this event processing method will be called when an application-level error occurs. Therefore, you can add code to this method to handle the error, as shown below:

Protected void application_error (Object sender, eventargs e ){
Exception objerr = server. getlasterror (). getbaseexception ();
Response. Write ("error:" + objerr. Message );
Server. clearerror ();
}

Here, we should pay attention to the use of server. clearerror () in the last code sentence. Why should we use this code? What if I don't need it? Here I want to sell another token. Well, the second type of error handling mechanism-the application_error event handling method in global. asax is also on stage.

 

The preceding two error handling methods can be said to be global. One is from the application configuration file, and the other is the event processing method that must be placed in the global. asax file under the application root directory. Compared to the global one, it is local, so we naturally think: Is there any error handling mechanism applied to a local page? The answer is "yes", and there are two other methods: Use the errorpage attribute and use the page_error event processing method. For the first mechanism, you can set the errorpage attribute almost anytime to determine the page to which the page will be redirected when an error occurs. For the second mechanism, it is similar to the application_error event processing method, except that the trigger time is different. The following are two examples:

<Script language = "C #" runat = "server">
Protected void page_load (Object sender, eventargs e ){
This. errorpage = "errorpage.htm"; www.bitscn.com

}
</SCRIPT>

 

 

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.
}

At this point, all four error handling mechanisms have been available, and it is time to rank them. From high priority to low priority: page_error event handling method> errorpage attribute> application_error event handling method> <customerrors> configuration item. Although the sorting is like this, there is a subtle relationship between the sorting. First, to enable the errorpage attribute to play a role, the mode attribute in the <customerrors> configuration item must be set to "ON". Second, although the page_error event processing method is at the top, if the server is missing. clearerror () method still causes lower-priority error handling, which is also true for application_error events. The order is arranged, but the order is not the most important. It can be said that there is not much significance, because in many cases, you may not mix these four processing mechanisms. I think the most important question is how to use these error handling mechanisms. We hope that experienced users can talk about this issue.

Now, let's take a look at ASP. NET's four error handling mechanisms. The designers of ASP. NET have made comprehensive considerations from the developer's perspective. Therefore, they provide up to four error handling mechanisms for us to choose from. This is commendable. However, when we use an advertisement word-many confusing words, we will also feel dizzy with so many error handling mechanisms. Comparing with the error handling in the J2EE field, we can find that it is relatively simple. First, it corresponds to the <customerrors> Settings. find similar configuration items in the XML file: <errorpage>. Second, in the J2EE field, page is not an important entity and the event-driven model is not required, therefore, I still cannot find the processing mechanism corresponding to application_error and page_error methods. Finally, in the J2EE field, more emphasis is placed on request and response, once an error occurs in logic processing, we can easily distribute the request to the corresponding error processing module through requestdispatcher. In fact, this is a very flexible way to handle it, if you are interested, please take a look.

[Transferred from www.bitscn.com]