对于一个Web应用程序来说出错是在所难免的因此我们应该未雨绸缪为可能出现的错误提供恰当的处理事实上良好的错误处理机制正是衡量Web应用程序好坏的一个重要标准试想一下当用户不小心在浏览器输入了错误的URL或者当用户提供了一些信息导致程序出错的时候如果我们没有对这些情况进行处理而是任由或是的错误页面甚至出错的堆栈信息呈现在用户面前这无疑会把一些用户给吓跑所以在我们开发Web应用程序的时候应该对错误处理机制有充分的了解
让我们回到ASPNET上来先提两个问题让大家思考一下ASPNET为我们提供了几种错误处理机制呢？如果同时采用了几种错误处理机制它们之间是否存在一定的优先级呢？带着这个问题我们先来看一下我们最常见的WebConfig文件
<?xml version=?>
<configuration>
<systemweb>
<customErrors mode=On defaultRedirect=>
<error statusCode= redirect= />
<error statusCode= redirect= />
</customErrors>
</systemweb>
</configuration>
对于<customErrors>这个设置项我想无需多言了详情可以参考MSDN的第一种错误处理机制——使用WebConfig的<customErrors>配置项应该是大家最常用的
接着我们再看另外一个也很常用的文件Globalasax提到这个文件大家想到了什么呢？对就是跟两大Web应用程序对象（ApplicationSession）相关的事件了在这些事件当中有一个属于Application范畴的与错误相关的事件——Error而对应的事件处理方法就是Application_Error了顾名思义这个事件处理方法在应用程序级别错误发生的时候就会被调用因此你可以在这个方法中添加代码来对错误进行处理如下所示
protected void Application_Error(object sender EventArgs e) {
Exception objErr = ServerGetLastError()GetBaseException();
ResponseWrite(Error: + objErrMessage);
ServerClearError();
}
在这里大家要注意最后一句代码的使用ServerClearError()为什么要使用这句代码呢？如果不用又会怎样呢？在这里我又先卖个关子好了第二种错误处理机制——使用Globalasax中的Application_Error事件处理方法也登台亮相了
以上这两种错误处理方法都可以说是全局性的一个源自应用程序配置文件一个则是必须放在应用程序根目录下的Globalasax文件的事件处理方法与全局相对的就是局部所以我们很自然的就会想有没有应用于局部——某个页面的错误处理机制呢？答案是有的而且还有两种————使用ErrorPage属性以及使用Page_Error事件处理方法对于第一种机制你几乎可以在任何时候设置ErrorPage属性从而确定页面发生错误的时候会重定向至哪个页面对于第二种机制而言它与Application_Error事件处理方法是很类似的只不过被触发的时机不同而已以下是具体的两个例子
<script language=C# runat=server>
protected void Page_Load(object sender EventArgs e) {
thisErrorPage = ;
}
</script>
protected void Page_Error(object sender EventArgs e) {
Exception objErr = ServerGetLastError()GetBaseException();
ResponseWrite(Error: + objErrMessage);
ServerClearError(); //同样要注意这句代码的使用
}
至此四种错误处理机制已经悉数登场是时候给它们排个名次了从优先级高到低排序Page_Error事件处理方法 > ErrorPage属性 > Application_Error事件处理方法 > <customErrors>配置项虽然排序是这样但是这个排序之间又有微妙的关系首先要让ErrorPage属性能够发挥作用<customErrors>配置项中的mode属性必须设为On其次虽然Page_Error事件处理方法排在最前面但是如果少掉了ServerClearError()方法的话仍然会引发优先级较低的错误处理这种情况对于Application_Error事件处理方法也是如此顺序是排好了但是顺序却不是最重要的问题甚至可以说是没有太多意义的问题因为在很多情况下你可能并不会混合使用这四种处理机制我想最重要的问题还是在如何选用这些错误处理机制上对于这个问题希望有经验的朋友能够谈谈看法
好了关于ASPNET的四种错误处理机制就介绍到这里也该说说自己的一些感受了ASPNET的设计者确实站在开发者的角度作了周全的考虑因此提供了多达四种的错误处理机制供我们选用这一点是值得称道的但是套用一句广告词——多则惑我们也会被这么多的错误处理机制弄得有些头晕对照JEE领域中的错误处理我们可以发现会相对简单一些首先是对应<customErrors>的设置我们也可以从JEE项目最常用的webxml文件中找到类似的配置项<errorPage>其次在JEE的领域中Page并不是一个重要的实体而且事件驱动模型也不是必需的所以我还真的找不到与Application_Error和Page_Error方法对应处理机制最后在JEE的领域中更多强调的是Request和Response一旦在逻辑处理中出现了错误我们可以很容易地通过RequestDispatcher将Request分发到相应的错误处理模块中事实上这是非常灵活的一种处理方式有兴趣的朋友不妨了解一下
