Asp.net error handling

Custom error page


Although the public error message we send to the user is secure, that is, it does not threaten the secret of the application, but such information is not good-looking. Maybe you want users to never see such information. On the contrary,
When an error occurs during request processing, you want to display your custom error page and your brand and specific error information.

It is easy to add custom error messages to ASP. NET applications. First, write your own web page, which can be any type of Files:. htm,. aspx,. asp, and so on. Modify the configuration information in the config. Web file of the application to point it to the file.

For example, the following configuration information indicates that the browser should be redirected to the "errorpage. aspx" page in case of any unscheduled handling error:

<Configuration>
<Customerrors mode = "remoteonly" defaultredirect = "errorpage. aspx"
/> </Configuration>

<Customerrors>
The defaultredirect attribute in the tag defines the "default" page to which the user will be redirected when an error occurs. Alternatively, the response can be returned Based on the HTTP code status,
Redirect to other pages to overwrite this default value. For example, redirect to a special "file not found" error page, "illegal access" error page, or "server conflict" error page.

For example, the following configuration information overwrites three specific HTTP status codes, and all other errors are returned to a default page:

<Customerrors
Defaultredirect = "http: // anotherhost/error. aspx" mode = "remoteonly">
<Error statuscode = "500"
Redirect = "http:/anotherhost/pages/callsupport.html"/>
<Error statuscode = "404"
Redirect = "http:/anotherhost/pages/adminmessage.html"/>
<Error statuscode = "403"
Redirect = "http:/anotherhost/pages/noaccess.html"/>
</Customerrors>

One thing we have encountered on the custom error page is that although
However, they are very useful for completed situations, but they are very difficult to deal with during the development process. Because you have come up with bugs in the development process, and you really want to see the actual errors when you find them.
Information Tracking. To solve this problem, the <customerrors> tag supports a "Mode" attribute with three values:

"On": indicates that custom error pages are always sent;

"Off": indicates that the custom error page is never sent (you always see the original error message );

"Remoteonly": indicates that a custom error page is issued only when a remote browser clicks the site (the developer clicking the site on the actual machine sees the detailed error information ).

 

2. Add the application error code to the Global. asax file and write it to the system log file.

 

Code
Protected void application_error (Object sender, eventargs E)
{
Exception lasterror = server. getlasterror ();
String errmessage = lasterror. tostring ();

String LOGNAME = "mylog ";
String message = "url" + request. Path + "error:" + errmessage;

// Create Event Log if it doesn' t exist

If (! EventLog. sourceexists (LOGNAME ))
{
EventLog. createeventsource (LOGNAME, LOGNAME );
}
EventLog log = new EventLog ();
Log. Source = LOGNAME;
// These are the five options that will display a different icon.
Log. writeentry (message, eventlogentrytype. Information, 1 );
Log. writeentry (message, eventlogentrytype. error, 2 );
Log. writeentry (message, eventlogentrytype. Warning, 3 );
Log. writeentry (message, eventlogentrytype. successaudit, 4 );
Log. writeentry (message, eventlogentrytype. failureaudit, 5 );

}
========================================================== =

　
For a web application, errors are inevitable. Therefore, we should plan ahead to provide appropriate solutions for possible errors. In fact, a good error handling mechanism is a measure of Web applications.
An important standard for program quality. If you accidentally enter a wrong URL in your browser or provide some information that may cause a program error
Instead, the stack information of 404 or 500 error pages or even errors is displayed in front of the user, which will undoubtedly scare some users away. Therefore, when developing Web applications, we should be right or wrong
The error handling mechanism is well understood.

Let's go back to ASP. NET and raise two questions for everyone to think about: ASP. NET provides several error handling mechanisms for us? If several error handling mechanisms are used at the same time
Is there a certain priority between them? With this problem, let's 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>
For the <customerrors> setting item, I don't need to talk about it any more. For details, refer to msdn. The first error handling mechanism-using the <customerrors> configuration item of Web. config should be the most commonly used.

Next, let's look at another commonly used file: Global. asax. What do you think of when talking about this file? Yes, it is the same as the two web application objects.
(Application, session) related events. Among these events, there is an error-related event in the application scope-error, and
The corresponding event processing method is application_error. As the name suggests, this event processing method will be called when an application-level error occurs, so you can
Add code to handle the error as follows:

Protected void
Application_error (Object sender, eventargs e ){
Exception objerr = server. getlasterror (). getbaseexception ();
Response. Write ("error:" + objerr. Message );
Server. clearerror ();
}

Here, we should pay attention to the use of the last code server. clearerror (). Why should we use this code? What if I don't need it? Here I want to sell another service.
Child. Well, the second type of error handling mechanism-the application_error event handling method in global. asax is also on stage.

The above two error handling methods can be said to be global. One is from the application configuration file, and the other is the event handler that must be placed in the global. asax file under the application root directory.
Method. Compared to the global one, it is local, so we naturally think: Is there any error handling mechanism applied to a local page? The answer is "yes", and there are two more ---- use
Errorpage attribute and how to handle page_error events. For the first mechanism, you can set the errorpage attribute almost anytime to determine whether a page occurs.
Which page will be redirected when an error occurs. For the second mechanism, it is similar to the application_error event processing method, except that the trigger time is different. Below
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 (); // pay attention to the use of this Code.
}
At this point, all four error handling mechanisms have been available, and it is time to rank them. Sorting from priority to low: page_error event handling method>
Errorpage property> application_error event handling method>
<Customerrors> configuration item. Although the sorting is like this, there is a subtle relationship between the sorting. First, make the errorpage attribute take effect,
<Customerrors> the mode attribute in the configuration item must be set to "ON". Secondly, although the page_error event processing method is at the top, if it is missing
Server. clearerror () method will still cause lower-priority error handling. In this case, the application_error event processing method is also shown in
Here. The order is arranged, but the order is not the most important. It can be said that there is not much significance, because in many cases, you may not mix these four processing mechanisms. I think, the most important
The problem is how to choose these error handling mechanisms. We hope that experienced users can talk about this issue.

Now, let's take a look at ASP. NET's four error handling mechanisms. ASP. NET designers have made comprehensive considerations from the developer's perspective,
Therefore, it is commendable that up to four error handling mechanisms are provided for us to choose from. However, when we use an advertisement word-many confusing words, we will also feel dizzy with so many error handling mechanisms. Comparison
In the J2EE field, we can find that it is relatively simple. First, it corresponds to the setting of <customerrors>.
Similar configuration items are found in the web. xml file: <errorpage>. Second, in the J2EE field, page is not an important entity and the event-driven model is not required.
So I still cannot find the processing mechanism corresponding to the application_error and page_error methods. Finally, in the J2EE field, more emphasis is placed on
Request and response. Once an error occurs in the logic processing, we can easily distribute the request to the corresponding
In the error handling module, this is actually a very flexible processing method.