ASP.NET项目开发中的异常处理

ASP.NET项目开发中的异常处理
 
            前言：异常的处理在项目开发中是很有必要的，异常的处理不仅仅只是try..catch..finally就完事了的。异常处理绝对可以称开发中的重要组成部分。必须正确的面对异常，因为即使是最能干的开发人员，也要面对这个问题 ....
        我们不知道客户是怎么样使用我们开发的软件的，所以我们必须处理这样的情况：如果系统不按照我们的设计时所想的运行，我们改怎么办？
       下面我们就来具体的介绍在ASP.NET项目开发中的异常的处理方式，希望看完后，大家可以回答上面的问题。
       本篇的话题如下：
       应用程序级别异常处理的错误处理
        页面级别异常处理
        方法级别异常处理
        web.config文件异常处理配置
        健康监视(Health Monitoring)
        Enterprise Application Blocks异常处理模块  
      一.在应用程序级别的异常处理：
        相信大家对Application对象不陌生，而且在项目中添加过Global.asax文件。确实，ASP.NET在应用程序级别处理异常的代码都是放在Global.asax的Application_Error事件处理下的：
  void Application_Error(object sender, EventArgs e)
  {
   // Code that runs when an unhandled error occurs
  }         我们可以在上面的事件处理的方法中捕获所有的异常，而且还可以把异常记录到日志文件，并且同时发送Email告诉开发人员出现了什么问题，如下
      
  void Application_Error(object sender, EventArgs e) 
     { 
         //在出现未处理的错误时运行的代码 页面或方法里已经处理的异常此处不会处理
         Exception ex = this.Server.GetLastError().InnerException;
         IS.Common.Log.Debug(ex); //log4net操作类
         Response.Redirect("ErrorPage.aspx");
     } 
       上面的代码，如果我们不在最后加了Response.Redirect方法，出错后，用户看到的就是那个很经典的黄颜色的报错的页面。我们也知道，那个经典的报错页面会暴露很多的信息，所以我们常常导航到我们自定义的错误页面。
  
  
          二.页面级的异常处理
        除了在Global.asax中编写处理代码，我们还可以在页面的Page_Error中编写代码：
  public void Page_Error(object sender, EventArgs e)
  {
   //Insert same code that is in the Application_Error event.
  }
  
        如果在该页面中发生了错误，那么页面中的上面的那段代码就会执行，我们可以把之前写在Application_Error事件中的代码全部copy到Page_Error处理方法中。但是，如果这样，那么我们的Application_Error中的代码就不运行了，因为异常已经在之前，也就是Page_Error中被处理了。
  
        三 方法级别的处理
        相信这点大家非常的熟悉了，就是常见的try..catch..finally语句块的运用，这里不赘述。
  
        四 web.config配置       我们处理异常一般在web.config文件中配置 <customErrors />节点：
             
  <!--<customErrors mode="Off">-->
  <!--<customErrors mode="On">-->
  <customErrors mode="RemoteOnly" defaultRedirect="ErrorPage.aspx">
   <error statusCode="403" redirect="NoAccess.htm" />
   <error statusCode="404" redirect="FileNotFound.htm" />
  </customErrors>        节点中的一些属性，大家也应该很熟悉，我不罗嗦了。
       五 健康监视(Health Monitoring)
  
        Health Monitoring是ASP.NET2.0以后版本添加的新的特性。它可以允许开发人员监视应用程序中发生的异常的事件。而且监视应用程序的启动，关闭，验证等都有相对应的事件来监视。而且我们还可以创建自定义的事件来监视应用程序中的特定的部分。我们也可以在Health Monitoring中配置把应用程序中的异常是记录在系统的日志中还是Sql Server中，或者是以Email形式发送出去。最重要的一点就是：只要通过配置，我们可以少写，甚至不写代码就可以实现强大的异常处理策略(和类似Enterprise Application Blocks，我们后面会提到的)。
         同样，我们还是在web.config中添加配置，在system.web节点中添加<healthMonitoring />节点：
       默认情况下是禁用的，我们启用就应该如下：
  
  
        Code
 <healthMonitoring enabled=”true>
   <eventMappings></eventMappings>
   <providers></providers>
   <rules>..</rules>
   <profiles>..</profiles>
   <bufferModes>..</bufferModes>
  </healthMonitoring>        下面就看看该节点下的一些配置：
        eventMappings节点通过指定事件类型来注册事件类。也就说，要注明我们在应用程序中要监听哪些事件，如下配置：  <eventMappings>
   <clear />
   <add name=”CustomException” type=”System.Web.Management.WebBaseErrorEvent” />
  </eventMappings>
  
        前面的"name"属性是我们自己为后面的事件取的友好的名称，从<eventMappings>的字面意思也可以知道：事件的映射。
        后面的"type"就是我们要在程序中监听的事件。之前也说过，我们可以监听很多的事件：系统的启动，关闭，验证失败等。       如上所见："System.Web.Management.WebBaseErrorEvent" 是所有事件的基类。它的子类有很多：
       WebApplicationLifetimeEvent－－在应用程序的运行过程触发的事情，如，当应用程序开启，关闭时
        WebAuthenticationFailureAuditEvent－－当ASP.NET验证失败是触发
        WebAuthenticationSuccessAuditEvent－－验证成功时触发
        WebRequestErrorEvent－－请求出错时触发
  
        除此之外，我们还可以自定义一些类，派生自基类。
  
  
        当我们确定了要监听的事件之后，我们就要选择事件的provider，也就说，事件触发后，我们把事情的信息记录到那里。
        配置如下：
    <providers>
   <clear />
   <add name=”EventLogProvider” type=”System.Web.Management.EventLogWebEventProvider” />
  </providers>
  
        这之前一样：System.Web.Management.EventLogWebEventProvider是个基类，有很多的子类，这些子类可以使得我们把异常的记录在如sql数据库中，系统日志中等：
        SqlWebEventProvider－－把异常信息记录到数据库中的提供程序
        SimpleMailEventProvider－－把异常信息通过Email发送的提供程序
  
        还有一些，大家参看MSDN。
  
        好了，到这里，我们把要监听的事件选择好了，如要监听WebApplicationLifetimeEvent，WebRequestErrorEvent；而且我们也准备把异常系统通过Email发送，我们选择了SimpleMailEventProvider，通过也想把异常记录到数据库中，我们也选择了SqlWebEventProvider。那么我们的配置就如下：
        Code
 <healthMonitoring enabled=”true>
   <eventMappings>
    <clear />
    <add name=”CustomException” type=”System.Web.Management.WebApplicationLifetimeEvent” />
    <add name=”AnotherException" type=”System.Web.Management.WebRequestErrorEvent” />
   </eventMappings>  <providers>
    <clear />
    <add name=”EmailProvider” type=”System.Web.Management.SimpleMailEventProvider” />
    <add name=”SqlProvider” type=”System.Web.Management.WebRequestErrorEvent” />
   </providers>
   
  </healthMonitoring>          注意：providers节点中的"name"属性也是我们自己取的友好的名称。
       好了，该定义的定义好了，现在还是不能按照我们的要求工作，那是因为我们还缺少一个"规则":
        如下： 
            
Code
 <rules>
   <clear />
   <add name=”Unhandled Exceptions Rule”
    eventName=”Unhandled Exceptions”
    provider=”EventLogProvider”
    profile=”Default”
    minInstances=”1”
    maxLimit=”Infinite”
    minInterval=”00:00:00” />
  </rules> 实际上，rules就是把我们之前定义的要监听的事件和相应的provider对象上来：
  
  <rules>
   <clear />
   <add name=”MyRules1”
    eventName=”CustomException”
    provider=”EmailProvider”
    profile=”Default”
    minInstances=”1”
    maxLimit=”Infinite”
    minInterval=”00:00:00” />
  </rules>         注意上面的name属性，其实和之前一样，我们是给这个规则取个名字而已。eventName就是之前我们定义的事件名称，如"CustomException",provider为之前定义的“EmailProvider” ，本条规则就是说，让EmailProvider来处理CustomException的异常信息。其他的同理。
  
        最后一点要注意的就是：如果我们决定发送Email，那么我们还要配置节点：
  <system.net>
   <mailSettings>
    <smtp deliveryMethod=”PickupDirectoryFromIis”>
     <network defaultCredentials=”true” host=”127.0.0.1” />
    </smtp>
   </mailSettings>
  </system.net>        这样就行了。