ASP.net错误处理（转）

使用定制错误页面
  
   虽然我们发送给用户的公用错误信息是安全的，就是说它不会威胁到应用程序的秘密，但是这样的信息并不好看。也许你希望用户永远也看不到这样的信息。相反， 当处理请求的过程中，如果发生了一个为处理的错误，你希望能够显示自己的“定制错误页面”，显示出自己的品牌以及特定的错误信息。

向ASP.NET 应用程序中增加定制错误信息非常容易。首先，编写自己的 web页面，它可以是任何类型的文件：.htm，.aspx，.asp，等等。然后在应用程序的config.web文件中修改配置信息，让它指向这个文件。

举例说明，以下这个配置信息说明在发生了任何未能预定处理错误的情况下，浏览器都应该被重定向到“ErrorPage.aspx”页面：

<configuration> <customerrors mode="remoteonly" defaultredirect="ErrorPage.aspx" /> </configuration>

<customerrors> 标记中的“defaultredirect”属性定义了在发生错误的情况下，用户将被重定向到的“默认”页面。或者，也可以根据响应的http代码状态， 重定向到其它的页面来覆盖这个默认值。例如：重定向到一个特殊的“未找到文件”错误页面、“非法访问”错误页面、“服务器冲突”错误页面等等。

举例说明，以下的配置信息覆盖3个特定的http 状态代码，所有其它错误都返回到一个默认页面：

<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>

在定制错误页面上有一件事我们已经遇到过，那就是虽 然它们对于已经完成的情况非常有用，然而在开发过程中却非常难以对付。因为你预想到在开发过程中会有bug，并且当你发现的时候，真的希望看到实际的错误 信息跟踪。为了解决这个问题，<customerrors>标记支持一个有3个值的“mode”属性：

“on”：意思是总是发出定制错误页面；

“off”：意思是从不发出定制错误页面（你总是看到原始的错误信息）；

“remoteonly”：意思是只有当远程浏览器点击站点时才发出定制错误页面（而在实际机器上点击站点的开发人员看到的是详细的错误信息）。

二,在Global.asax文件中添加应用出错代码，写入系统日志文件

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);


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

　 对于一个Web应用程序来说，出错是在所难免的，因此我们应该未雨绸缪，为可能出现的错误提供恰当的处理。事实上，良好的错误处理机制正是衡量Web应用 程序好坏的一个重要标准。试想一下，当用户不小心在浏览器输入了错误的URL或者当用户提供了一些信息导致程序出错的时候，如果我们没有对这些情况进行处 理，而是任由404或是500的错误页面甚至出错的堆栈信息呈现在用户面前，这无疑会把一些用户给吓跑。所以，在我们开发Web应用程序的时候，应该对错 误处理机制有充分的了解。

　　让我们回到ASP.NET上来，先提两个问题让大家思考一下：ASP.NET为我们提供了几种错误处理机制呢？如果同时采用了几种错误处理机制，它们 之间是否存在一定的优先级呢？带着这个问题，我们先来看一下我们最常见的Web.Config文件：

＜?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＞
　　对于＜customErrors＞这个设置项，我想无需多言了，详情可以参考MSDN的。第一种错误处理机制——使用Web.Config的＜customErrors＞配置项应该是大家最常用的。

　　接着，我们再看另外一个也很常用的文件：Global.asax。提到这个文件，大家想到了什么呢？对，就是跟两大Web应用程序对象 （Application、Session）相关的事件了。在这些事件当中，有一个属于Application范畴的与错误相关的事件——Error，而 对应的事件处理方法就是Application_Error了。顾名思义，这个事件处理方法在应用程序级别错误发生的时候就会被调用，因此你可以在这个方 法中添加代码来对错误进行处理，如下所示：

protected void Application_Error(object sender, EventArgs e) {
　Exception objErr = Server.GetLastError().GetBaseException();
　Response.Write("Error:" + objErr.Message);
　Server.ClearError();
}
　　在这里，大家要注意最后一句代码Server.ClearError()的使用，为什么要使用这句代码呢？如果不用又会怎样呢？在这里我又先卖个关 子。好了，第二种错误处理机制——使用Global.asax中的Application_Error事件处理方法也登台亮相了。

　　以上这两种错误处理方法都可以说是全局性的，一个源自应用程序配置文件，一个则是必须放在应用程序根目录下的Global.asax文件的事件处理方 法。与全局相对的就是局部，所以我们很自然的就会想：有没有应用于局部——某个页面的错误处理机制呢？答案是“有的”，而且还有两种————使用 ErrorPage属性以及使用Page_Error事件处理方法。对于第一种机制，你几乎可以在任何时候设置ErrorPage属性，从而确定页面发生 错误的时候会重定向至哪个页面；对于第二种机制而言，它与Application_Error事件处理方法是很类似的，只不过被触发的时机不同而已。以下 是具体的两个例子：

＜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(); //同样要注意这句代码的使用
}
　　至此，四种错误处理机制已经悉数登场，是时候给它们排个名次了。从优先级高到低排序：Page_Error事件处理方法 ＞ ErrorPage属性 ＞ Application_Error事件处理方法 ＞ ＜customErrors＞配置项。虽然排序是这样，但是这个排序之间又有微妙的关系。首先，要让ErrorPage属性能够发挥作用， ＜customErrors＞配置项中的mode属性必须设为"On"；其次，虽然Page_Error事件处理方法排在最前面，但是，如果少掉了 Server.ClearError()方法的话，仍然会引发优先级较低的错误处理，这种情况对于Application_Error事件处理方法也是如 此。顺序是排好了，但是顺序却不是最重要的问题，甚至可以说是没有太多意义的问题，因为在很多情况下，你可能并不会混合使用这四种处理机制。我想，最重要 的问题还是在如何选用这些错误处理机制上。对于这个问题，希望有经验的朋友能够谈谈看法。

　　好了，关于ASP.NET的四种错误处理机制就介绍到这里，也该说说自己的一些感受了。ASP.NET的设计者确实站在开发者的角度作了周全的考虑， 因此提供了多达四种的错误处理机制供我们选用，这一点是值得称道的。但是套用一句广告词——多则惑，我们也会被这么多的错误处理机制弄得有些头晕。对照 J2EE领域中的错误处理，我们可以发现会相对简单一些。首先是对应＜customErrors＞的设置，我们也可以从J2EE项目最常用的 web.xml文件中找到类似的配置项：＜errorPage＞；其次，在J2EE的领域中，Page并不是一个重要的实体而且事件驱动模型也不是必需 的，所以我还真的找不到与Application_Error和Page_Error方法对应的处理机制；最后，在J2EE的领域中，更多强调的是 Request和Response，一旦在逻辑处理中出现了错误，我们可以很容易地通过RequestDispatcher将Request分发到相应的 错误处理模块中，事实上这是非常灵活的一种处理方式