ASP. NET page error handling

ASP. NET applications can use exception capture in code to handle errors (try and catch). However, exception capture is a bad programming habit. Try and catch are easy to use, but excessive use may cause serious performance loss. If exceptions can be detected, try to use other methods, and use exception capture as the final consideration. Exception capture is an official application processing tool provided by NET. If ASP. when an exception occurs in the. NET application, the runtime will try to find the code block that intends to capture it. The exception will be traversed in the lower part of the stack until it reaches the starting layer of the current application, if no proper handler is found during this period, the exception becomes an unhandled exception and the CLR throws a system exception. The user will see the yellow pages and the application will terminate immediately.
The default error page displays different typical error pages on the Local Computer and remote computer.
The local user will see relatively detailed error information, and the information received by the remote user will not be so detailed. This is mainly for security considerations.
ASP. NET provides two levels of global interception points, respectively at the page level and application level, to help us handle errors programmatically. An Error event is exposed based on the base-class Page. You can rewrite the Error event on the Page to capture the unhandled exceptions caused during Page execution. Similarly, there is an Error event in the HttpApplication class, which is used to capture the exceptions thrown in the entire application.

Page-Level Error Handling

protected override void OnError(EventArgs e){    Exception ex = Server.GetLastError();    if (ex is NotImplementedException)        Server.Transfer("ErrorPages/NotImplemented.aspx");    else        Server.Transfer("ErrorPages/AppError.aspx");    Server.ClearError();} 

The GetLastError method of the Server object is used to obtain the thrown exception. Then, it is uploaded to a specific page and displayed to the user. Once the Exception Processing is completed, the application calls ClearError to identify the error.

Global error handling

Page Error event processing can capture errors on specific pages. To share a set of Error processing code for all pages of the combined application, we can create a global Error processing program at the application level, you can capture all unhandled exceptions. The implementation is almost the same as the page-level Error handler, except that the Error event in the HttpApplication object of the entire application is handled. Therefore, we need. add the asax file to the program and define the Application_Error method:

protected override void OnError(EventArgs e){    Exception ex = Server.GetLastError();    if (ex is NotImplementedException)        Server.Transfer("ErrorPages/NotImplemented.aspx");    else        Server.Transfer("ErrorPages/AppError.aspx");    Server.ClearError();} 

Incorrect page ing

ASP. NET will report yellow pages, but we can also use the application Web. the <mermerrors> section in the Config file can fully control this function.

<configuration>  <system.web>    <customErrors mode="Off">    </customErrors>  </system.web></configuration>

The mode attribute is used to determine whether an error message is started, closed, or only displayed to a remote client.
When the mode is set to RemoteOnly, the remote user will receive a general error prompt page, and the local user can get detailed error information.
When mode is set to off, both local and remote users will display pages with detailed errors.
Customizable error pages

<configuration>  <system.web>    <customErrors mode="Off" defaultRedirect="GenericErrorPage.htm">    </customErrors>  </system.web></configuration>

If the mode is on, the defaultRedirect = "GenericErrorPage.htm" page will be replaced by the original Error Reporting yellow page for both local and remote users to display friendly error prompts, most custom error pages are written in HTML only.

Common HTTP Error Handling

ASP. NET also enables you to display custom pages for different HTTP errors. The ing between the error page and a specific HTTP status can be defined in the <customErrors> section, set the <error> label, and set the HTTP status code
Associated with custom error pages:

<configuration>  <system.web>    <customErrors mode="Off" defaultRedirect="GenericErrorPage.htm">      <error statusCode="403" redirect="NoAccess.htm"/>      <error statusCode="404" redirect="FileNotFound.htm"/>    </customErrors>  </system.web></configuration>