Asp. NET error-handling mechanism

Error is unavoidable for a Web application, so we should take precautions and provide appropriate treatment for possible errors. In fact, a good error-handling mechanism is an important criterion for measuring the quality of Web applications. Imagine that when the user accidentally enters the wrong URL in the browser or when the user provides some information that causes the program to go wrong, if we do not deal with these cases, but let the 404 or 500 of the error page or even the wrong stack of information presented to the user, this will undoubtedly give some users to scare away. So, when we develop Web applications, we should have a good understanding of the error handling mechanism.

Let's go back to ASP.net and ask two questions to think about: ASP.net provides us with several error-handling mechanisms? If several error-handling mechanisms are in use, are there certain priorities between them? With this problem, let's take a look at our most common Web.config files:

＜?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＞

I don't need to say a word about this setting, but I'll refer to MSDN for more details. The first error-handling mechanism-the use of Web.config configuration items should be the most commonly used.

Next, we look at another file that is also very popular: Global.asax. Referring to this document, what do you think of? Yes, it's an event related to two big Web application objects (application, sessions). Among these events, there is an error-related event--error belonging to the application category, and the corresponding event-handling method is Application_Error. As the name suggests, this event-handling method is invoked when an application-level error occurs, so you can add code in this 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 line of code Server.ClearError (), why use this code? And what if it doesn't? Here I sell a case. Well, 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 originating from the application configuration file, the other being the event-handling method of the Global.asax file that must be placed in the application's root directory. And the global relative is the local, so we will naturally think: there is no application in the local-a page error handling mechanism? The answer is "yes," and there are two other ———— using the ErrorPage property and using the Page_Error event-handling method. For the first mechanism, you can almost at any time set the ErrorPage property to determine which page the page will redirect to when the error occurs, and for the second mechanism it is very similar to the Application_Error event approach, except that the timing of the trigger is different. Here are two specific examples: