Introduction to Asp. Net custom error pages

Aside from Try Catch, ASP. NET provides four error handling mechanisms: Page_Error, ErrorPage, Application_Error, and <customErrors>. If you add Try Catch, you can understand it as follows: A local variable --- Try Catch; two page-level variables: Page_Error and ErrorPage; two global variables: Application_Error and customErrors. Here we will explain their execution sequence in advance, from high to low sorting: Page_Error> ErrorPage> Application_Error> <customErrors> The following describes how to use these four commands in detail.
First of all, when we look at the word Page_Error, we can basically understand what it means, that is, the page-level processing program, A page error, and A's Page_Error processes A's error, page B has an error. The Page_Error of page B processes the error of page B. You can understand it like try catch, but this is a bit larger than try catch. A try catch method contains a try catch, if an error occurs in this method, it will be processed in catch. If a page error occurs, it will be processed in Page_Error.

 

Usage: add this method to the page.

Protected void Page_Load (object sender, EventArgs e)

{

// Operations after an error, such as writing logs, output the expected error message to the user

}

Advantage: flexible processing. You can simply add pages with frequent errors.

Disadvantage: it is a page-level variable. More often, we don't know which pages will encounter errors. Therefore, if you use this processing method, you need to write all the pages, which is troublesome.

 

Second, ErrorPage and Page_Error are very similar. We can think of them as front-end js processing and page-level processing programs, but they are not recommended here. They may be due to habits and I personally feel ASP. NET is the most important aspect of asp than the code Postfix. In this case, why do I have to write things on the background at the front end? Haha ,.. Of course, this is also a personal habit. A lot of things must be written at the front-end. That's no way to do it. Let's take a look at his usage.

 

Usage: add this method to the page.

<Script language = "C #" runat = "server">

Protected void Page_Load (object sender, EventArgs e)

 

{

This. ErrorPage = "ErrorPage.htm ";

}

</Script>
Advantage: see Page_Error

Disadvantage: see Page_Error

 

Third: Application_Error. Familiar with ASP. NET people will know at a glance that it belongs to Global. global variables in asax are indeed a global processing mechanism. We should not only ask: Application_Error and customErrors are global variables. What are their differences? The inconsistency in the mechanism is not mentioned here. The usage is different. customErrors only allows you to jump to the desired page and cannot record error information, it will automatically process the error. Application_Error can receive and process the error messages.

 

Usage: The Application_Error method is automatically generated in Global. asax.

Protected void Application_Error (object sender, EventArgs e)

 

{

 

Exception ex = this. Context. Server. GetLastError ();

 

If (ex! = Null)

 

{

 

This. Context. Server. Transfer ("/Error. aspx ");

 

// Logs can be written here, or logs can be written by Error, and a friendly interface is displayed to the user.

 

This. Context. Response. Clear ();

 

}

 

}
Advantage: global variables are written once here. If errors occur on all pages, the error page is automatically redirected, saving time and effort, and relevant errors can be recorded.
Disadvantage: global variables are clearly identified, and some performance needs to be consumed.

Fourth: customErrors in fact, customErrors is a configuration item of Web. config. After it is configured here, the page will automatically jump to the corresponding error page after an error occurs, which is believed to have been used frequently. Here is a brief introduction.

Usage:

<System. web>

<CustomErrors mode = "On" defaultRedirect = "GenericErrorPage.htm">

<Error statusCode = "403" redirect = "Error403.htm"/>

<Error statusCode = "404" redirect = "Error404.htm"/>

</CustomErrors>

</System. web>
Advantage: For those page connections that do not exist or program errors, the user is prompted with a friendly, this is a lot

Disadvantage: Unable to record specific error information