asp.net 使用自定义的错误页面

Introduction

Every application should have error handling.  We try totrap errors using try-catch-finally block.  But what happens in the case of anunhandled exception in application?  ASP.NET produces an error page (usuallylocated at c:\winnt\help\iishelp\common) when an application throws anunhandled exception or when we deploy an .aspx file whose source contains asyntax error without compiling it inside Visual Studio .NET first.  By default,ASP.NET displays error messages that include .NET error description along witha stack trace (see Figure 1).  There is a lot of information in the errormessage.  The stack trace points out the location where the specific erroroccurred and the last line informs us about the version used in .NET Framework. This information is very useful for a developer because it tells why and wherethe error occurred.  

On the other hand, it may confuse the general user as he orshe will not understand anything by seeing the displayed error message.  As aresult, it may create a bad opinion in his or her mind and even may be thereason for loss of business.  Even hackers use the information displayed in theerror message with a bad intention in mind as the line of code might contain confidentialinformation, such as the password to access a database.   We do not want thispage be visible to the site's visitors and we should redirect the browser to acustom error page on which we can instruct users about error causes andpossible remedies.  ASP.NET provides several levels at which we can handle andrespond to errors that may occur when we run an ASP.NET application.  Thisarticle will also provide some code which can be used to create custom errorpages for ASP.NET web applications.  Although this article describes how toprovide custom error pages and general error reporting, it is not going todescribe error handling using try-catch-finally block.  The sample codesnippets in this article have been written in C#.

Solution

ASP.NET provides three main methods that allow us to trapand respond to errors when they occur.

Page_Error of .aspx file or associated codebehind

Application_Error in Global.ascx file

CustomErrors section of the application configuration files(Web.config)

Sequence of Events

The actual order of error handling events is as follows.

Page_Error of .aspx file or associated codebehind

Application_Error in Global.ascx file

CustomErrors section of the application configuration files(Web.config)

Server.ClearError and Server.GetLastError

Two important server side methods named Server.ClearErrorand Server.GetLastError are used in the following code listing.  Here is abrief description of these two methods.

Server.ClearError: Use this method to handle the exceptionand stop the error to trigger the subsequent error event or display the errorto the user.  If we do not clear the exception by using the Server.ClearError,the unhandled exception will continue to propagate up to the Application_Errorevent.  If we use Server.ClearError to clear the exception inApplication_Error, the default redirect setting in the Web.config file will notredirect the user because the unhandled exception no longer exists.  If youwant the default redirect setting to properly redirect users, do not clear theexception in Application_Error.

Server.GetLastError: A call to Server.GetLastError willreturn the most recent error.

Page_Error Method

ASP.NET provides as the 1st level of error handling by meansof Page_Error event handler which provides a way to trap errors that occur atthe page level in a web application.  The following example throws a divide byzero exception which forces an error to occur in the Page_Load event handler.  Todemonstrate Page_Error event handler we have to create or add a new web form(say) named as PageError.aspx and then we should add the following code toPageError.aspx.

Listing 1

<script language=C# runat="server">
void Page_Load(object sender, System.EventArgs e)
{
      int i=0;
      int j=5;
      int k=0;
      k=j/k;
}
 
public void Page_Error(object sender,EventArgs e)
{
      Exception objError = Server.GetLastError().GetBaseException();
      string strError = "<b>Error Has Been Caught in Page_Error event</b><hr><br>" + 
                  "<br><b>Error in: </b>" + Request.Url.ToString() +
                  "<br><b>Error Message: </b>" + objError.Message.ToString()+
                  "<br><b>Stack Trace:</b><br>" + 
                        objError.StackTrace.ToString();
      Response.Write(strError.ToString());
      Server.ClearError();
}
</script> 


 AutoEventWireup

The AutoEventWireup attribute may have a value of true orfalse.  When an ASP.NET Web Application is created by using Microsoft VisualStudio .NET, the value of the AutoEventWireup attribute is set as false.  Inthis code sample the AutoEventWireup attribute is not explicitly set.  If you donot explicitly assign a value to the AutoEventWireup attribute, the defaultvalue true is used.  There is an important difference between the default valuethat ASP.NET uses and the default value that the Visual Studio .NET templatecode assigns to this attribute.  If the AutoEventWireup attribute value is setto false, the event handlers that are declared in the .ASPX page do not fire.  Totest the same you can write AutoEventWireup=”false” and then you will see thata white page is coming without showing the content of Figure1. 

Listing 2

<%@ Page language="c#" Codebehind="PageError.aspx.cs" AutoEventWireup="false" Inherits="CustomError.PageError" %>

After saving the page, when we run the application we willsee that the error is thrown and reported according to the code specifications. The following screen shot (see Figure 1) describes the error handled by thePage_Error event handler.

Figure 1


asp.net 使用自定义的错误页面_第1张图片

Application Error Method

Along with page level error handlers, ASP.NET givesdevelopers the ability to provide application-level error handling.  Thepage-level error handling comes first, after ASP.NET calls the Page_Errorprocedure, and then ASP.NET calls the Application_Error procedure.  We can simplydisplay error information, log the event to the Windows Event Log, send E-mailto system administrator or we can simply redirect to another page.

The Application_Error event handler is specified in theGlobal.asax file of our application.

Here a new page named ApplicationError.aspx is added and thefollowing code is written in that page to generate the error.

Listing 3

<script language=C# runat="server">
  void Page_Load(object sender, System.EventArgs e)
  {
    int i=0;
    int j=5;
    int k=0;
    k=j/k;
  }
</script>


The AutoEventWireup attribute as discussed in the "Page_Error"section also applies to the code sample in this step.  To trap the errorgenerated in the page load of ApplicationError.aspx using the above codelisting we have to add the following code to the Global.asax file.

Add the following namespace to use the event log.

Listing 4

using System.Diagnostics;

Add the following code in Application_Error event to trapthe error that will be thrown in the Page_Load event handler of theApplicationError.aspx page.

Listing 5

public void Page_Error(object sender,EventArgs e)
{
      Exception objError = Server.GetLastError().GetBaseException();
      string strError = "<b>Error Has Been Caught in Page_Error event</b><hr><br>" + 
                  "<br><b>Error in: </b>" + Request.Url.ToString() +
                  "<br><b>Error Message: </b>" + objError.Message.ToString()+
                  "<br><b>Stack Trace:</b><br>" + 
                        objError.StackTrace.ToString();
      Response.Write(strError.ToString());
      Server.ClearError();
}
</script> 


If we right-click the page and then click View in the Browser,the page will be blank (i.e. white screen).  However, we should notice that anew entry has been added in the event log.  This sample makes an entry in theApplication log which is accessible from the Event Viewer.

In this function we can even save error information tosession state and then perform the redirect manually.

Listing 6

protected void Application_Error(Object sender, EventArgs e)
{
  Exception objError = Server.GetLastError().GetBaseException();
  string strError = "Error Has Been Caught in Application_Error event\n" +
    "Error in: " + Request.Url.ToString() + "\nError Message:" +
    objError.Message.ToString() + "\nStack Trace:" +
    objError.StackTrace.ToString();
  Session["error"] = strError.ToString();
  Server.Transfer("WebForm1.aspx");
 
}


Now, on the custom error page we will have access to all theinformation pertaining to the error.  We can then use this for errorreporting via email to the developers/system admin or to display a morepleasing error message.

Understanding Web.config File

<customErrors> section is responsible for handling theerror on the basis of the setting made in that section if we do not call Server.ClearError,trap the error in the Page_Error or Application_Error event handler.  In the<customErrors> section we can specify a redirect page as a default errorpage (defaultRedirect) or specify to a particular page based on the HTTP errorcode that is raised.  We can use this method to customize the error messagethat the user receives.
If an error occurs that is not trapped at any of the previous levels in theapplication (i.e. either in page level or in application level), this custompage is displayed.

In the following code, Server.ClearError() ; is commented inthe Application_Error event of  the Global.asax file so that Server.ClearErroris never called.  This means the error will be handled on the basis of thesetting made in <customErrors> section in the Web.config file.

Listing 7

using System.Diagnostics;
protected void Application_Error(object sender, EventArgs e)
{
  Exception objError = Server.GetLastError().GetBaseException();
  string strError = "Error Has Been Caught in Application_Error event\n" +
    "Error in: " + Request.Url.ToString() + "\nError Message:" +
    objError.Message.ToString() + "\nStack Trace:" +
    objError.StackTrace.ToString();
  EventLog.WriteEntry("CustomError", strError, EventLogEntryType.Error);
//Server.ClearError();
}    

Add the following code to the <customErrors> sectionto redirect the user to a custom page.

Listing 8

<customErrors defaultRedirect="http://hostName/applicationName/CustomError.htm" mode="On"></customErrors>

We should modify the file path in defaultRedirect attributeso that it references the relevant Web server and application names.

Because the errors that are trapped at this level are sentto a default error page, you must create an error page named CustomError.htm.  Keepin mind that you are using this method to control what is presented to theuser, so this example uses an .htm page for the error page.  Add the followingcode to CustomError.htm.

Listing 9

<HTML>
<HEAD>Custom Error Page</HEAD>
<BODY>
<H1><FONT COLOR=RED>There is a problem in site. Please try again later. </FONT> </H1>
</BODY><HTML>


It should be noted that a custom error page may be a simpleHTML file or an ASPX file; it depends upon requirements.

If we run ApplicationError.aspx in the browser, we will seethat when the error is thrown we are redirected to the CustomError.htm page.

In the above code listing the <customErrors> sectionincludes a mode attribute that is set to On. The mode attribute is used tocontrol how the error redirection occurs.  For example, if anyone is developingthe application, he or she most likely wants to see the actual ASP.NET errormessages and does not want to be redirected to the more user-friendly errorpage.  The mode attribute includes the following settings or options.

On: This option specifies thatcustom errors are enabled.  If no defaultRedirect is specified, users see ageneric error.

Off: This option specifies thatcustom errors are disabled.  This allows the display of detailed errors.

RemoteOnly: This option specifiesthat custom errors are shown only to remote clients and ASP.NET errors areshown to the local host.  This is the default.

Note that defaultRedirect optional attribute specifies thedefault URL to direct a browser if an error occurs.  When defaultRedirect isnot specified, a generic error is displayed instead.  The URL may be absolute(for instance, http://localhost/CustomErrorPage.htm) or it may be relative.  Arelative URL such as /CustomErrorPage.htm is relative to the Web.config filethat specified the defaultRedirect URL and not to the Web page in which theerror occurred.

Handling specific errors

The customErrors section of the web.config file allows us tohandle individual errors differently. Errors are distinguished by their HTTPerror codes; we can also specify a particular page to redirect to that is basedon the HTTP error code that is raised.

The followings are some of the most common errors.

400: Bad Request - This means the request could not beunderstood by the server.  Therequest                                                   

        was denied due to a syntax error in the request.

401:  Unauthorized - This means the request requiresauthentication.

402: Payment required - This means the data is notaccessible at the time.  The owner of the    

       space has not yet paid his or her service provider orthe server was unable to serve the data

       that was requested.

403: Forbidden - This means the IP address or theusername/password entered were not correct  

       and the request was denied as there was no permissionto access the data.

404: Not found - This means the document requested either nolonger exists or has            

       never existed on the server.

405: Method not allowed- Means the method you are using toaccess the document is not

       allowed.

408: Request Timeout - Means the server has closed thesocket due to communications

        between the client and server taking too long.

414: The URL requested is too long.

500: Internal server error. The server encountered an error- This is most often caused by a

        scripting problem, a failed database access attempt,or similar reasons.

503: Service unavailable- This means the server isoverloaded or down for maintenance and was

       unable to process the client request.

A complete HTTP status code listing is available online.  Wemay expand the customErrors section of the web.config file to handle specificerror codes.  We can achieve the expansion by adding error elements under thecustomErrors element.  The following sample shows how we may accomplish this.

Listing 10

<customErrors mode="RemoteOnly" defaultRedirect="CustomErrorPage.aspx"><error statusCode="400" redirect="ErrorPage400.aspx" /><error statusCode="401" redirect="ErrorPage401.aspx" /><error statusCode="402" redirect="ErrorPage402.aspx" /><error statusCode="403" redirect="ErrorPage403.aspx" /><error statusCode="404" redirect="ErrorPage404.aspx" /><error statusCode="408" redirect="ErrorPage408.aspx" /><error statusCode="414" redirect="ErrorPage414.aspx" /><error statusCode="500" redirect="ErrorPage500.aspx" /><error statusCode="503" redirect="ErrorPage503.aspx" /></customErrors>

The above sample handles each specific error with thecorresponding page.  The statusCode attribute of the error element designatesthe error and the redirect attribute defines the page to use.  This allows usto customize the error message based upon the error encountered.  The defaulterror page handles any error that is not specified.

References

ExceptionManagement

Conclusion

This article provides a detailed overview of ASP.NET customerror pages and several different methods to implement them.  When an errorwill occur, end users should always have a view of meaningful and friendly errorpages.  At the same time, it is also important that people on the other end (theadministrator or developers) are alerted about problems.  Using the Custom ErrorPage we can also provide the page with the site’s look and feel.  Custom errorpage design becomes a normal part of site design.


转载地址:http://aspalliance.com/articleViewer.aspx?aId=1008&pId=-1

你可能感兴趣的:(exception,server,File,application,asp.net,redirect)