<script language="C#" runat="server">
   protected void Page_Load(object sender, EventArgs e) { /?"
   this.ErrorPage = "ErrorPage.htm";
  
   }
  </script>
  
  
  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()方法的话，仍然会引发优先级较低的错误处理，这种情况对于Application_Error事件处理方法也是如此。顺序是排好了，但是顺序却不是最重要的问题，甚至可以说是没有太多意义的问题，因为在很多情况下，你可能并不会混合使用这四种处理机制。我想，最重要的问题还是在如何选用这些错误处理机制上。对于这个问题，希望有经验的朋友能够谈谈看法。
  
   好了，关于ASP.NET的四种错误处理机制就介绍到这里，也该说说自己的一些感受了。ASP.NET的设计者确实站在开发者的角度作了周全的考虑，因此提供了多达四种的错误处理机制供我们选用，这一点是值得称道的。但是套用一句广告词——多则惑，我们也会被这么多的错误处理机制弄得有些头晕。对照J2EE领域中的错误处理，我们可以发现会相对简单一些。首先是对应<customErrors>的设置，我们也可以从J2EE项目最常用的web.xml文件中找到类似的配置项：<errorPage>；其次，在J2EE的领域中，Page并不是一个重要的实体而且事件驱动模型也不是必需的，所以我还真的找不到与Application_Error和Page_Error方法对应处理机制；最后，在J2EE的领域中，更多强调的是Request和Response，一旦在逻辑处理中出现了错误，我们可以很容易地通过RequestDispatcher将Request分发到相应的错误处理模块中，事实上这是非常灵活的一种处理方式，有兴趣的朋友不妨了解一下。
  
  转自：动态网站制作指南 | www.acnow.net
  
    ()。