对于一个web应用程序来说，出错是在所难免的，因此我们应该未雨绸缪，为可能出现的错误提供恰当的处理。事实上，良好的错误处理机制正是衡量web应用程序好坏的一个重要标准。试想一下，当用户不小心在浏览器输入了错误的url或者当用户提供了一些信息导致程序出错的时候，如果我们没有对这些情况进行处理，而是任由404或是500的错误页面甚至出错的堆栈信息呈现在用户面前，这无疑会把一些用户给吓跑。所以，在我们开发web应用程序的时候，应该对错误处理机制有充分的了解。
     　　让我们回到asp.net上来，先提两个问题让大家思考一下：asp.net为我们提供了几种错误处理机制呢?如果同时采用了几种错误处理机制，它们之间是否存在一定的优先级呢?带着这个问题，我们先来看一下我们最常见的web.config文件：
     　　
     　　
     　　
     　　
     　　
     　　
     　　
     　　
     　　
    
     　　对于这个设置项，我想无需多言了，详情可以参考msdn的。第一种错误处理机制——使用web.config的配置项应该是大家最常用的。
     　　接着，我们再看另外一个也很常用的文件：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事件处理方法是很类似的，只不过被触发的时机不同而已。以下是具体的两个例子：
    
     　　protected void page_load(object sender, eventargs e) {
     　　this.errorpage = "errorpage.htm";
     　　}
     　　
     　　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事件处理方法 > 配置项。虽然排序是这样，但是这个排序之间又有微妙的关系。首先，要让errorpage属性能够发挥作用，配置项中的mode属性必须设为"on"; 其次，虽然page_error事件处理方法排在最前面，但是，如果少掉了server.clearerror()方法的话，仍然会引发优先级较低的错误处理，这种情况对于application_error事件处理方法也是如此。顺序是排好了，但是顺序却不是最重要的问题，甚至可以说是没有太多意义的问题，因为在很多情况下，你可能并不会混合使用这四种处理机制。我想，最重要的问题还是在如何选用这些错误处理机制上。对于这个问题，希望有经验的朋友能够谈谈看法。
     　　好了，关于asp.net的四种错误处理机制就介绍到这里，也该说说自己的一些感受了。asp.net的设计者确实站在开发者的角度作了周全的考虑，因此提供了多达四种的错误处理机制供我们选用，这一点是值得称道的。但是套用一句广告词——多则惑，我们也会被这么多的错误处理机制弄得有些头晕。对照j2ee领域中的错误处理，我们可以发现会相对简单一些。首先是对应的设置，我们也可以从j2ee项目最常用的web.xml文件中找到类似的配置项：; 其次，在j2ee的领域中，page并不是一个重要的实体而且事件驱动模型也不是必需的，所以我还真的找不到与application_error和page_error方法对应处理机制; 最后，在j2ee的领域中，更多强调的是request和response，一旦在逻辑处理中出现了错误，我们可以很容易地通过requestdispatcher将request分发到相应的错误处理模块中，事实上这是非常灵活的一种处理方式，有兴趣的朋友不妨了解一下。
    

注:IT公司速查网所有信息来自互联网