Asp. Error handling support in net (turn)

Asp.net| Error | error handling ASP. Error handling support in net

Asp. NET has a good new feature: it provides rich support for handling and tracking run-time errors. In particular, it provides an easy way for managers to ensure that scary "ASP 43433ax" hexadecimal errors are never displayed to customers. Instead, it allows the display of a more customized message, such as "Sorry, this site is not available." Asp. NET also provides a powerful way for developers to equip their code to provide managers with additional information and notifications of problems that occur at work sites. This article describes the two techniques in detail, and at the end includes a sample code that you can experiment with directly.

Ensure that security information is not compromised

Asp. NET as with previous ASPs, an HTML error page is generated when a run-time or compile-time error occurs on the server. However, unlike ASP, ASP. NET is particularly concerned: to ensure that, by default, "security" information is not compromised because of this error. Especially if you click on a server from a remote machine. Error-handling settings for the out of the box will not result in the display of compiler information for remote machines, disclosure of configuration information, file names, stack records, source code, or linear data. Instead, remote users will only see a common message such as "An application error has occurred." To view the error details, the user must: 1 click the page again from the local server, or 2, modify the configured settings in the machine or application Config.web file to allow remote access:

<configuration>
<customerrors mode= "Off"/>
</configuration>

We want to ultimately help protect the integrity and security of the application by setting the default state to the way we have to be "secure." And this corrects a common complaint/concern that many ASP developers-especially ASP executives are reflecting.

Using custom error pages

Although the common error message that we send to the user is safe, that is, it does not threaten the application's secret, this information is not good. Perhaps you want users to never see such information. Conversely, when processing a request, if an error occurs for processing, you want to be able to display your own "custom error page" Showing your brand and specific error messages.

It is easy to add custom error messages to the ASP.net application. First, write your own web page, which can be any type of file:. htm,.aspx,.asp, and so on. Then modify the configuration information in the application's Config.web file to point it to this file.

For example, the following configuration information indicates that the browser should be redirected to the "errorpage.aspx" page in the event of any failure to schedule a processing error:

<configuration>
<customerrors mode= "RemoteOnly" defaultredirect= "errorpage.aspx"/>
</configuration>

The "defaultredirect" property in the <customerrors> tag defines the default page that the user will be redirected to if an error occurs. Alternatively, you can override this default value by redirecting to another page based on the HTTP code state of the response. For example, redirect to a special "File not Found" error page, "Illegal access" error page, "Server Conflict" error page, and so on.

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

<customerrors defaultredirect= "http://anotherhost/error.aspx" mode= "RemoteOnly" >
<error statuscode= "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've already encountered on the custom error page is that although they are useful for what has been done, they are extremely difficult to deal with in the development process. Because you think there will be bugs in the development process, and when you find out, you really want to see the actual error message tracking. To solve this problem, the,<customerrors> tag supports a "mode" attribute with 3 values:

"On": it means always making a custom error page;

"Off" means that you never emit custom error pages (you always see the original error message);

"RemoteOnly" means that a custom error page is only issued when a remote browser clicks on the site (and the developer who clicks the site on the actual machine sees a detailed error message).

Equip applications to help administrators track errors

While it's a good idea to display custom error messages to your customers, you might still want to make it easy for developers and administrators to spot it in real time when an error occurs on the site and identify what the problem, URL, and exception information is.

To solve this problem, ASP. NET introduces a new "application layer" event that can be processed in a Global.asax file: "Application_Error". When a Web request is processed, the method is invoked when an unhandled exception occurs. The developer can obtain special information about the request, such as the URL to eject the page, the query string variable, the user agent, the value of the cookie, and so on, and information about the actual exception object that encapsulates the error message. You can then go ahead and run any logic that they want to track and use to inform administrators and developers about the problem, which may include writing information to net event logs using System.diagnostic APIs, using System.Web.Util SMTP Email APIs send emails to administrators, write information to a database, and so on.

For example, the following Global.asax file demonstrates how to write an error message to a custom NT event log "Mycustomlog", including the page URL and exception stack record:

<%@ Import namespace= "System.Diagnostics"%>
<script language= "VB" runat=server>
Sub Application_Error (Sender as Object, E as EventArgs)
' Obtain the URL of the Request
Dim Pageurl as String = Request.path
' Obtain the Exception Object for the Error
Dim errorinfo as Exception = Server.GetLastError ()
' Construct Error message to Write to NT Event Log
Dim message as String = "Url" & Pageurl
Message = message & "Error:"
Message = message & errorinfo.tostring
' NT Event Log Name to Write
Dim LogName as String = "Mycustomlog"
' Create Event Log if It doesn ' t Exist
If (not eventlog.sourceexists (LogName)) Then
EventLog.CreateEventSource (LogName, LogName)
End If
' Fire off to Event Log
Dim Log as New EventLog
Log.source = LogName
Log.writeentry (message, EventLogEntryType.Error)
End Sub
</script>

To see how everything is actually working, try creating a new IIS application vroot on the machine, and then copying the sample code above into a new "global.asax" file that was created in the application root directory. Then, copy/paste the following code fragment into the "blowup.aspx" file:

<body>
<%
Dim x
X.blowup ()
%>
</body>

Note that this file always causes a run-time error because it causes an invalid reference exception, and the "X" object is not created at all, and there is no "blowup" method. Therefore, when you click on the page in the browser, you will see an error message.

In addition to seeing the error message in the browser, you will see it in the NT event log because of the Application_Error event inside the global.asax. To see this, select the Start menu-> Program-> Admin Tool-> Event Viewer, and then click on the "Mycustomlog" node on the right to display the contents of the log. You can see the URL of the page and the recording details of the stack by double-clicking on its internal specific item.

Note: NT Event logs can be viewed remotely, so this is an easy way to track the state of a machine from a distance. Also note that when you create a new NT event log dynamically, you must exit and restart the NT Event Viewer each time in order to see it appear in the list.

Now that we can easily track the details of the error when there is a problem within the new ASP.net application, we need to make sure that our customers see only friendly custom error messages. This will create a "customerror.aspx" page in VRoot:

<body>
</body>

Then modify the Config.web file to point to this page:

<configuration>
<customerrors mode= "on" defaultredirect= "customerror.aspx"/>
</configuration>

Click the blowup.aspx page again and you will see that the browser is automatically redirected to the friendly error page. If you look at the NT event log, you will see all the details necessary to notify an administrator of this error, as well as all the details that the developer needs to identify and fix it.

Note that because the customer information information is stored in the Config.web file instead of the IIS metadata, it can be installed through "xcopied" without requiring the user to use the IIS Admin tool. Asp. NET, this custom function also works in IIS4 and IIS5.