For a web application, errors are inevitable, so we should take precautions and provide appropriate handling for possible errors. In fact, good error handling mechanism is an important criterion for measuring the quality of web applications. Just imagine, when the user accidentally enters the wrong URL in the browser or when the user provides some information that causes the program to error, if we do not handle these situations, we allow 404 or 500 error pages or even errors. The stack information is presented in front of users, which will undoubtedly scare some users away. Therefore, when we develop web applications, we should have a full understanding of the error handling mechanism.
Let's go back to ASP.NET and ask two questions for everyone to think about: How many error handling mechanisms does ASP.NET provide us with? If several error handling mechanisms are used at the same time, is there a certain priority between them? With this question in mind, let’s first 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>
Regarding the <customErrors> setting item, I think there is no need to say more. For details, please refer to MSDN. The first error handling mechanism - using the <customErrors> configuration item of Web.Config should be the most commonly used one.
Next, let’s look at another file that is also very commonly used: Global.asax. When you mention this document, what do you think of? Yes, they are events related to the two major Web application objects (Application and Session). Among these events, there is an error-related event that belongs to the Application category - Error, and the corresponding event processing method is Application_Error. As the name suggests, this event handling method will be called when an application-level error occurs, so you can add code in 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, everyone should pay attention to the use of Server.ClearError() in the last line of code. Why should this line of code be used? What happens if you don’t use it? Here I'll give it a try again. Well, the second error handling mechanism - using the Application_Error event handling method in Global.asax has also made its debut.
The above two error handling methods can be said to be global. One is derived from the application configuration file, and the other is the event handling method of the Global.asax file that must be placed in the application root directory. The opposite of the global is the local, so we naturally wonder: Is there an error handling mechanism that applies to the local - a certain page? The answer is "yes", and there are two ways - using the ErrorPage attribute and using the Page_Error event handling method. For the first mechanism, you can set the ErrorPage property almost at any time to determine which page will be redirected to when an error occurs on the page; for the second mechanism, it is very similar to the Application_Error event handling method, except that But the timing of being triggered is different. The following 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, the four error handling mechanisms have all appeared, and it is time to rank them. Sort from high priority to low: Page_Error event handling method > ErrorPage property > Application_Error event handling method > <customErrors> configuration item. Although the ranking is like this, there is a subtle relationship between the rankings. First of all, for the ErrorPage attribute to work, the mode attribute in the <customErrors> configuration item must be set to "On"; secondly, although the Page_Error event processing method is ranked first, if the Server.ClearError() method is missing If so, lower-priority error handling will still be triggered. This is also true for the Application_Error event handling method. The order is arranged, but the order is not the most important issue. It can even be said to be an issue that does not have much meaning, because in many cases, you may not mix these four processing mechanisms. I think the most important issue is how to choose these error handling mechanisms. Regarding this issue, I hope experienced friends can share their opinions.
Okay, that’s it for introducing the four error handling mechanisms of ASP.NET, and it’s time to talk about some of my own feelings. The designers of ASP.NET have indeed made thorough considerations from the perspective of developers, so they provide as many as four error handling mechanisms for us to choose from, which is commendable. But to paraphrase an advertising slogan - too much is confusing, we will also be a little dizzy with so many error handling mechanisms. Comparing error handling in the J2EE field, we can find that it is relatively simple. The first is the setting corresponding to <customErrors>. We can also find similar configuration items from the most commonly used web.xml file in J2EE projects: <errorPage>; secondly, in the field of J2EE, Page is not an important entity and event The driver model is not necessary, so I really can't find the corresponding processing mechanism for the Application_Error and Page_Error methods; finally, in the field of J2EE, more emphasis is placed on Request and Response. Once an error occurs in logical processing, We can easily distribute the Request to the corresponding error handling module through RequestDispatcher. In fact, this is a very flexible processing method. Friends who are interested may wish to learn about it.