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