Centralized exception handling by application_error in ASP. NET

There are two common methods for unified and centralized Exception Processing in ASP. NET:

1. Configure the customerrors node of Web. config and the defaultredirect attribute to redirect all "unprocessed exceptions" to the same page

2. write code through application_error in global. asax to implement the operations you want.

However, in actual use, some problems often occur, such as the Code in application_error is not executed, and how to pass the error information to the target page if customerrors is used.

Through my exploration, I have summarized some experiences and recorded them as follows:

1. You do not want to configure the web. in config, The customerrors method is used to perform page Jump. Instead, you want to write code in application_error for some processing and then use response. the redirect method redirects to the specified page. This theoretically good method doesn't actually work! Response. Redirect is written in application_error to jump to the page and will not be executed!

2. Many users do not want to use the Web configuration. the reason for automatic redirect of config errors is nothing more than jump to a "dead" link, and the current error information cannot be passed, so no corresponding processing can be performed! In fact, this is a misunderstanding. Any aspx web page can use server. getlasterror () to obtain the last exception. You can also use this. context. allerrors obtains all the unprocessed exceptions. You can also configure the page as long as it is An ASPX page.

// Obtain the latest exceptionexception EX = This. context. server. getlasterror (); // get all unprocessed exception sets exception [] errors = This. context. allerrors; // then you can process them.

3. Is it recommended that you use the combination of Web. config and application_error to handle exceptions on the Internet? Of course! But I personally think this is not a good idea, because there is no need.

Let's take a look at what they will do:

Web. config

<customErrors mode="On" defaultRedirect="Error.aspx">

Global. asax

Protected void application_error (Object sender, eventargs e) {// obtain the last exception EX = This. context. server. getlasterror (); // then perform a series of processing, write the file log, write the database. // clear the exception, OK. This. context. server. clearerror ();}

Error. aspx

Protected void page_load (Object sender, eventargs e) {// output the expected error page}

This seems okay. It's actually a big problem! You will find that it does not jump to the error. ASPX page! Why? Because the processing priority of application_error is higher than that of web. the custom error handling page configured in config. You have done all the tasks in application_error, and then sent the error to clear. At this time, the Web will no longer be triggered. the configuration in config is automatically redirected!

Some people will say that, after I finish processing in application_error, I will not execute the clearerror (). Will he jump over? That's right! In this way, you can jump, and you can even go to error. in aspx, retrieve this error again, and then give the user a "friendly" error prompt based on the error type. Finally, do not forget to execute clearerror. This can achieve the goal, but I really don't think it is necessary, why not, let's look at the following.

4. The reason why some people adopt the "3" approach is that they want to capture and handle the corresponding errors and give users a "friendly" Custom interface. To achieve this effect, you do not have to combine the two methods. You can do this in any way:

A. Check the Web. config configuration method first:

Web. config

<customErrors mode="On" defaultRedirect="Error.aspx">

Error. aspx

protected void Page_Load(object sender, EventArgs e){

// Obtain the latest exceptionexception EX = This. Context. server. getlasterror (); // then you can process them.

}

B. Use application_error for processing

Global. asax

Protected void application_error (Object sender, eventargs e) {// get exception EX = This. context. server. getlasterror (); // process exception // clear the current output this. context. response. clear (); // turn to the page where you want to display the error message to the user (at this time, the website is still the page with the error, however, the displayed content is exactly the page you specified.) This. context. server. transfer ("/error. aspx ");

// If you have to jump to the target page (that is, the address bar is also changed to error. aspx), you can handle it as needed.

　　　　　　　this.Context.Response.Write("<script>top.location.href='/Error.aspx';</script>");        }