Asp. NET error-handling mechanism

For a Web application, errors are unavoidable, so we should prepare for a rainy day and provide appropriate treatment for possible errors. In fact, a good error-handling mechanism is an important criterion for measuring the quality of a Web application. Imagine, when the user accidentally entered the wrong URL in the browser or when the user provided some information caused the program error, if we do not deal with these situations, but instead of 404 or 500 error page or even the wrong stack information presented in front of the user, this will undoubtedly scare some users away. Therefore, when we develop the Web application, we should have a good understanding of the error handling mechanism.

Let's go back to ASP. Two questions to ask you to think about:ASP. NET provides us with several error-handling mechanisms? If there are several error-handling mechanisms at the same time, are there certain priorities 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 <customErrors> This setting, I think there's no need to talk about it, for details can be found on MSDN. The first error-handling mechanism-the <customErrors> configuration item that uses Web. config should be the most common of all.

Next, let's look at another very common file: Global.asax. What do you think of this document? Yes, events related to the two major Web application objects (application, Session). In these events, there is an error-related event--error that belongs to the application category, and the corresponding event-handling method is Application_Error. As the name implies, this event-handling method is called when an application-level error occurs, so you can add code to the method to handle the error as follows:

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 last sentence of code server.clearerror (), why use this code? What if it doesn't? Here I sell a xiaoguanzi first. OK, the second error handling mechanism--using the Application_Error event handling method in Global.asax , is also on the stage.

Both of these error handling methods can be said to be global, one from the application configuration file, and one is the event-handling method that must be placed in the Global.asax file under the application root directory. Relative to the global is the local, so we will naturally think: there is no application to the local-a page error handling mechanism? The answer is "yes", and there are two ———— use the ErrorPage property and use the Page_Error event handling method . For the first mechanism, you can set the ErrorPage property almost at any time to determine which page is redirected to when the page is wrong, and for the second mechanism it is very similar to the Application_Error event handling method, except that the timing of the trigger is different. Here are two specific examples:

<script language= "C #" runat= "Server" >    protected void Page_Load (object sender, EventArgs e) {this        . ErrorPage = "errorpage.htm";            }   </script>

protected void Page_Error (object sender, EventArgs e) {    Exception objerr = Server.GetLastError (). GetBaseException ();    Response.Write ("Error:" + objerr.message);    Server.ClearError (); Also pay attention to the use of this code}

At this point, four error-handling mechanisms have been introduced, it is time to rank them. Sort by priority from high to Low:Page_Error Event Handling methods > ErrorPage Properties > Application_Error event Handling methods > <customErrors> configuration Items . Although this sort is the case, there is a subtle relationship between the sorts. First, to make the ErrorPage property work,<customerrors> The Mode property in the configuration item must be set to "on", and secondly, although the Page_Error event handling method is If the Server.ClearError () method is missing, it will still cause lower priority error handling, which means that the error handling mechanism such as the ErrorPage property will still work, so you won't get the results you want. This is also true of the Application_Error event handling method. The order is lined up, but the order is not the most important question, or even a problem that does not make much sense, 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. For this question, I hope that experienced friends can talk about their views.

Asp. NET error-handling mechanism