ASP.NET的错误处理机制
通常情况下,我们在写ASP.NET程序的时候,会经常遇到如何处理错误处理机制的问题.可以说一个良好的错误处理机制是衡量Web应用程序好坏的一个重要标准.
下面将介绍四中错误处理机制:
1.使用Web.Config的<customErrors>配置项
例子:
<?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>
2.使用Global.asax中的Application_Error事件处理方法
在这些事件当中，有一个属于Application范畴的与错误相关的事件——Error，而对应的事件处理方法就是Application_Error了。顾名思义，这个事件处理方法在应用程序级别错误发生的时候就会被调用，因此你可以在这个方法中添加代码来对错误进行处理，如下所示：
protected void Application_Error(object sender, EventArgs e) {
Exception objErr = Server.GetLastError().GetBaseException();
Response.Write("Error:" + objErr.Message);
Server.ClearError();
}
以上这两种错误处理方法都可以说是全局性的，一个源自应用程序配置文件，一个则是必须放在应用程序根目录下的Global.asax文件的事件处理方法。与全局相对的就是局部，所以我们很自然的就会想：有没有应用于局部——某个页面的错误处理机制呢？答案是“有的”，而且还有两种————使用ErrorPage属性以及使用Page_Error事件处理方法。
3.使用ErrorPage属性处理错误机制
你几乎可以在任何时候设置ErrorPage属性，从而确定页面发生错误的时候会重定向至哪个页面
<script language="C#" runat="server">
protected void Page_Load(object sender, EventArgs e) {
this.ErrorPage = "ErrorPage.htm";
}
</script>
4.使用Page_Error事件处理方法处理错误机制
与Application_Error事件处理方法是很类似的，只不过被触发的时机不同而已。
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()方法的话，仍然会引发优先级较低的错误处理，也就是说ErrorPage属性等错误处理机制仍然会发挥作用，这样就得不到你想要的结果了。这种情况对于Application_Error事件处理方法也是如此。顺序是排好了，但是顺序却不是最重要的问题，甚至可以说是没有太多意义的问题，因为在很多情况下，你可能并不会混合使用这四种处理机制。我想，最重要的问题还是在如何选用这些错误处理机制上。对于这个问题，希望有经验的朋友能够谈谈看法。
下面将介绍四中错误处理机制:
1.使用Web.Config的<customErrors>配置项
例子:
<?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>2.使用Global.asax中的Application_Error事件处理方法
在这些事件当中，有一个属于Application范畴的与错误相关的事件——Error，而对应的事件处理方法就是Application_Error了。顾名思义，这个事件处理方法在应用程序级别错误发生的时候就会被调用，因此你可以在这个方法中添加代码来对错误进行处理，如下所示：
protected void Application_Error(object sender, EventArgs e) {
Exception objErr = Server.GetLastError().GetBaseException(); Response.Write("Error:" + objErr.Message); Server.ClearError();}以上这两种错误处理方法都可以说是全局性的，一个源自应用程序配置文件，一个则是必须放在应用程序根目录下的Global.asax文件的事件处理方法。与全局相对的就是局部，所以我们很自然的就会想：有没有应用于局部——某个页面的错误处理机制呢？答案是“有的”，而且还有两种————使用ErrorPage属性以及使用Page_Error事件处理方法。
3.使用ErrorPage属性处理错误机制
你几乎可以在任何时候设置ErrorPage属性，从而确定页面发生错误的时候会重定向至哪个页面
<script language="C#" runat="server"> protected void Page_Load(object sender, EventArgs e) { this.ErrorPage = "ErrorPage.htm"; } </script>4.使用Page_Error事件处理方法处理错误机制
与Application_Error事件处理方法是很类似的，只不过被触发的时机不同而已。
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()方法的话，仍然会引发优先级较低的错误处理，也就是说ErrorPage属性等错误处理机制仍然会发挥作用，这样就得不到你想要的结果了。这种情况对于Application_Error事件处理方法也是如此。顺序是排好了，但是顺序却不是最重要的问题，甚至可以说是没有太多意义的问题，因为在很多情况下，你可能并不会混合使用这四种处理机制。我想，最重要的问题还是在如何选用这些错误处理机制上。对于这个问题，希望有经验的朋友能够谈谈看法。
