Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

An example Analysis of error handling Mechanism ASP.NET

2025-02-14 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/02 Report--

This article mainly explains "ASP.NET example Analysis of error handling Mechanism". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn "error handling mechanism ASP.NET example analysis" it!

For a Web application, errors are inevitable, so we should be prepared in advance to provide appropriate handling for possible errors. In fact, a good error handling mechanism is an important criterion to measure the quality of Web applications. Just imagine, when the user accidentally typed the wrong URL in the browser or when the user provided some information that caused the program to go wrong, if we did not deal with these situations, but let the error page or even the error stack information appear in front of the user, this will undoubtedly scare some users away. Therefore, 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 for you to think about: how many error handling mechanisms does ASP.NET provide for us? 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 take a look at our most common Web.Config file:

I think there is no need to say any more about this setting item. For details, please refer to MSDN's. * error handling mechanism-configuration items that use Web.Config should be the most commonly used.

Next, let's look at another file that is also commonly used: Global.asax. What do you think of when it comes to this document? Yes, these are the events related to the two major Web application objects (Application and Session). Among these events, there is an error-related event in the category of Application-Error, 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 this method to handle the error, as shown below:

ProtectedvoidApplication_Error (objectsender,EventArgse) {ExceptionobjErr=Server.GetLastError () .GetBaseException (); Response.Write ("Error:" + objErr.Message); Server.ClearError ();}

Here, you should pay attention to the use of the code Server.ClearError (). Why do you use this code? What happens if you don't use it? I'm going to sell it here again. Well, the second error handling mechanism, using the Application_Error event handling method in Global.asax, has also made its debut.

Both of these error handling methods can be said to be global, one originating from the application configuration file and the other 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 applied to the local-a particular page? The answer is yes, and there are two other ways-using the ErrorPage property and using Page_Error event handling. For the * * mechanism, you can set the ErrorPage attribute at almost any time to determine which page will be redirected when an error occurs; for the second mechanism, it is very similar to the Application_Error event handling method, except that it is triggered at a different time. Here are two specific examples:

ProtectedvoidPage_Load (objectsender,EventArgse) {this.ErrorPage= "ErrorPage.htm";} protectedvoidPage_Error (objectsender,EventArgse) {ExceptionobjErr=Server.GetLastError () .GetBaseException (); Response.Write ("Error:" + objErr.Message); Server.ClearError (); / / also note the use of this code}

So far, all four error handling mechanisms have been put on the scene, and it's time to rank them. Sort by priority: Page_Error event handling method > ErrorPage property > Application_Error event handling method > configuration item. Although the sort is like this, there is a delicate relationship between the sort. First of all, for the ErrorPage property to work, the mode property in the configuration item must be set to "On"; second, although the Page_Error event handling method comes first, if you lose the Server.ClearError () method, it will still cause a lower priority error handling, that is, error handling mechanisms such as the ErrorPage attribute will still work, so you won't get the results you want. The same is true for Application_Error event handling methods. The order is arranged, but the order is not the most important issue, or even a meaningless question, because in many cases, you may not mix these four processing mechanisms. I think the most important question is how to choose these error handling mechanisms. I hope experienced friends can express their views on this issue.

Well, this is the end of the four error handling mechanisms for ASP.NET, and it's time to talk about some of your feelings. The designers of ASP.NET do think carefully from the developer's point of view, so it is commendable that they provide as many as four error handling mechanisms for us to choose from. But to paraphrase a slogan-too many puzzles, we will also be a little dizzy by so many error handling mechanisms. Compared with the error handling in the J2EE domain, we can find that it is relatively simple. First of all, there are the corresponding settings, and we can also find similar configuration items in the most commonly used web.xml files of J2EE projects: secondly, in the domain of J2EE, Page is not an important entity and the event-driven model is not necessary, so I really can't find the processing mechanism corresponding to Application_Error and Page_Error methods. *, in the field of J2EE, more emphasis is placed on Request and Response. Once there are errors in logic processing, we can easily distribute Request to the corresponding error handling module through RequestDispatcher. In fact, this is a very flexible processing method, and interested friends may wish to learn about it.

At this point, I believe you have a deeper understanding of the "error handling mechanism ASP.NET example analysis", might as well come to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report