抛开Try Catch 不说（这种地球人都知道），ASP.NET提供了四种错误处理机制，分别为：Page_Error， ErrorPage，Application_Error，<customErrors>四种,如果加上Try Catch就算五种吧，可以理解为：一种局部变量---Try Catch ，两种页面级变量：Page_Error， ErrorPage，两个全局变量：Application_Error，customErrors，在这里提前说一下他们的执行顺序，从高到低排序：Page_Error > ErrorPage > Application_Error > <customErrors>下面将会按照这四种执行的高低顺序做一下详细的使用介绍。

首先：Page_Error 大家一看这个词语，估计大体上就明白了什么意思了，就是页面级处理程序，A页面出错了，A的Page_Error处理A的错误，B页面出错了，B的Page_Error处理B的错误，大家可以喝try catch一样理解，只是这个比try catch范围大了一些，一个方法里面有try catch，这个方法出错了，就在catch中处理，一个页面出错了，就在Page_Error中处理。

使用方法：在页面里面加入此方法即可

　　　　　　protected void Page_Load(object sender, EventArgs e)

　　　　　　{

　　　　　　　　　//错误后的操作如：写日志，给用户输出自己期望的错误信息

　　　　　　}

优点：处理比较灵活，对于经常出错的页面，直接添加就可以了。

缺点：他属于页面级变量，更多的时候，我们不知道那些页面会出错，所以如果使用这种处理方法，需要每个页面都写，比较麻烦

第二：ErrorPage 其实ErrorPage 和Page_Error非常类似，大家可以看做是前台js处理，也是页面级处理程序，但是在这里不推荐使用，可能是因为习惯问题，个人感觉ASP.NET比asp最方面的地方就是代码后置，既然这样，为什么能写在后台的东西，非要写在前台呢？呵呵，。。当然，这个也属于个人习惯，很多东西，必须写在前台，那是没办法的事情，好了扯远了，下面看一下他的用法

使用方法：在页面里面加入此方法即可

优点： 请参考Page_Error

缺点： 请参考Page_Error

第三： Application_Error 看到Application_Error，熟悉ASP.NET的人一眼就知道，它属于Global.asax中的全局变量，没错，它就是一个全局处理机制，我们不仅要问，Application_Error和customErrors都是全局变量，他们有什么不一致呢？机理上的不一致在这里就不说了，主要说一下用法上的不一样，customErrors只能让你跳到到你想要的页面，不能记录错误信息，它会自动处理掉，Application_Error可以接收和处理这些错误信息

使用方法：在Global.asax中处理，Application_Error方法Global会自动就生成了

优点：全局变量，在这里写一次，所有的页面出错了，都会自动跳转到错误页面，省时省力，并且可以记录相关错误

缺点：全局变量的确定大家都明白的，需要消耗一部分的性能

第四： customErrors 其实customErrors就是Web.config的一个配置项，在这里配置以后，页面出错后，会自动跳转到相应的错误页面，这种相信大家都用过非常频繁了。在这里就简单介绍一下了

使用方法：

优点：对于那些页面连接不存在，或者程序出错，给用户以友好的提示，这个用的是很多的

缺点：没法记录具体错误信息