Asp.net开发过程中，我们会遇到很多Exception

在Asp.net开发过程中，我们会遇到很多Exception，不处理这些Exception的话会出现很难看的页面。
还有一些我们未预料到的Exception，当发生Exception时，我们也必须进行记录具体位置，以便我们修正错误。
asp.net异常处理的位置大概有以下3个地方
1. 程序的代码段中，这是最直接处理异常的地方。如下
try
{
    n=Convert.ToInt32(info);
}
catch(Exception)
{
}
只是最基本处理异常的地方。

2. ASP.NET的中的Application_Error中.Application_Error 事件。对于应用程序中引发的任何未处理异常都会引发此事件。一般我们处理如下
protected void Application_Error(Object sender, EventArgs e)
  {
    Exception exp=Server.GetLastError();
    string strE="内部错误:"+ exp.InnerException.ToString()+"\r\n堆栈："+ exp.StackTrace+"\r "+"Message:"+exp.Message+"\r 来源:"+exp.Source;
   
   // 在事件日志中记录异常信息
   Log(strE);
   Server.ClearError();
   Server.Transfer("Error.aspx",false);
  }
这样我们就可以处理Server端出现的错误。我们记录出错的源头。

3. 也可以在页级别或者应用程序级别处理代码错误。Page 基类公开了一个 Page_Error 方法，此方法在页中可以被重写。每当运行时引发未捕获的异常时都调用此方法。
void Page_Error(Object source, EventArgs e) {
    String message = "<font face=verdana color=red>"
        + "<h4>" + Request.Url.ToString() + "</h4>"
        + "<pre><font color='red'>"
        + Server.GetLastError().ToString() + "</pre>"
        + "</font>";

    Response.Write(message);
}

 

下面我讲述一下怎么在ASP.NET程序里面统一的处理异常，我们以最常见的Session过期为例

我们先写一个Session过期的异常
public class YSessionException:Exception
{
}

我们再定义一个属性
public int SessionValue
{
     get{ if(Session["SessionValue"]==null)
            {
                throw new YSessionException("");
             }
          }
}

下面我们在Page_Error或者Application_Error中处理这个异常
  {
   Exception exp=Server.GetLastError();
                        if(exp is YSessionException)
                        {
                               ..................
                        }
                        Server.ClearError();
   Server.Transfer("Error.aspx",false);
  }

这样就可以为我们程序提供很好的Exception处理界面。

 

 

 

            前言：异常的处理在项目开发中是很有必要的，异常的处理不仅仅只是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告诉开发人员出现了什么问题，如下

      


Exception error = Server.GetLastError().GetBaseException();
//在事件日志中记录异常
if (!EventLog.SourceExists("ApplicationException"))
{
        EventLog.CreateEventSource("ApplicationException", "Application");
}

EventLog eventLog = new EventLog();
eventLog.Log = "Application";
eventLog.Source = "ApplicationException";
eventLog.WriteEntry(error.ToString(), EventLogEntryType.Error);

//发送Email给开发人员
MailMessage email = new MailMessage("administrator@xiaoyang.com",
"vince.varallo@PoweredByV2.com");
email.Body = error.ToString();
email.Subject = "An error occurred in the  Application";
SmtpClient smtpClient = new SmtpClient("127.0.0.1", 25);
smtpClient.Send(email);
Response.Redirect("ErrorPage.aspx");




        当然，上面的代码要正确的运行，我们海必须在Global.asax中加入相应的命名空间，而且在发送邮件的时候，上面的"127.0.0.1"要换为我们自己的邮件服务器的地址：
 

<%@ Import Namespace="System.Diagnostics" %>
 <%@ Import Namespace="System.Net.Mail" %>
复制代码


 
 
       还有一点要注意的就是，ASP.NET运行时是以ASPNET账户运行的，这个账户的权限是有限的，如果我们想要使得上面的代码可以运行，那么就必须要给ASPNET账户访问注册表的权限。如果你不给权限，那么上面的代码就报错。


       我们赋予ASPNET账户访问在"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog"节点以及字节点的权限。
       下面就讲讲如何配置权限：
       1.打开"运行"菜单
       2.输入"regedit"，然后确定
       3.导航到"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog"节点。
       4.右击这个节点，并且选择"权限",此时就会弹出权限配置的窗口。
       5.点击"添加"，在弹出的窗口中点击"高级"，之后再点击"查找",最后在下面的窗口找到"ASPNET"账户，确定。
       6.最后给予ASPNET账户读的权限就OK了。

       上面的代码，如果我们不在最后加了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="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 />节点：

       默认情况下是禁用的，我们启用就应该如下：
 
 
       


<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。那么我们的配置就如下：
       


<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


        注意上面的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>
复制代码

 

       这样就行了。
 


       六 Enterprise Application Blocks 

      关于Enterprise Application Blocks，相信大家都知道，在异常处理的时候我们一般用Exception Handling Application Block(后面简称 ：异常处理的模块)，Logging Application Block。
       在决定用Enterprise Application Blocks的时候，我们必须首先下载安装包. 
       得到了安装包之后，我们就开始安装，如果在安装的过程中，全部采用默认的安装设置，那么我们就会有c:\EntLib4Src\Quick Starts文件夹。而且在ExceptionHandling\CS子文件夹下有ExceptionHandlingBasicQuickStart.sln 和ExceptionHanldingWithLoggingQuickStart.sln。打开ExceptionHandlingWithLoggingQuickStart解决方案，这个方案是个告诉我们如果使用异常处理模块的Demo。


       而且这个Demo是WinForm的，因为我们谈的是在ASP.NET使用异常处理的模块。所以我们谈谈在ASP.NET如何使用。
       在此之前，我们要熟悉一些配置节点，其实这些节点的结构和我们之前谈的"健康监视"很相似：

 <exceptionTypes>
  <add name=”Exception” type=”System.Exception, mscorlib, Version=2.0.0.0,
   Culture=neutral, PublicKeyToken=b77a5c561934e089” postHandlingAction=”None”>

 </exceptionTypes>
复制代码


       上面节点表示要处理的异常，和之前的<eventMappings>相似。

 

 <exceptionHandlers>
  <add name=”Application Message Handler” type=”ExceptionHandlingQuickStart.AppMessageExceptionHandler,
   ExceptionHandlingWithLoggingQuickStart”/>
 </exceptionHandlers>
复制代码

 

       异常处理模块，就是异常发生后，如何处理。和之前的providers节点类似。
 
       下面的节点，看起来很吓人的，其实是声明异常信息以什么格式记录：

       


<formatters>
  <add name=”Default Formatter”
   type=”Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter,
   Microsoft.Practices.EnterpriseLibrary.Logging”
   template=”Timestamp: {timestamp}
   Message: {message}
   Category: {category}
   Priority: {priority}
   EventId: {eventid}
   Severity: {severity}
   Title:{title}
   Machine: {machine}
   Application Domain: {appDomain}
   Process Id: {processId}
   Process Name: {processName}
   Win32 Thread Id: {win32ThreadId}
   Thread Name: {threadName}
   Extended Properties: {dictionary({key} - {value})}”
  />


       最后的节点如下，也不难理解，和之前说的rules节点类似：
             


<listeners>
  <add name=”Event Log Destination”
   type=”Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.Formatt        edEventLogTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging”
    listenerDataType=”   Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FormattedEventLogTraceListenerData,
   Microsoft.Practices.EnterpriseLibrary.Logging”
   source =”Enterprise Library Logging”
   formatter=”Default Formatter”
  /> 
 
 </listeners>

 

       其实Enterprise Application Blocks的功能不仅强大，而且还有最大的好处就是可以用GUI图形化的形式来配置，不必项之前一样要亲自在配置文件中写配置。而且在代码调用方面也很简单，几句话就OK了。
 

       说完上面的之后，我们就用图文结合的方式，展示如何使用异常处理模块。      


       首先，我们把Program Files\Microsoft Enterprise Library 4.1 - October 2008\bin目录下的几个dll引入到我们的ASP.NET项目中：
       Microsoft.Practices.EnterpriseLibrary.Common
       Microsoft.Practices.EnterpriseLibrary.ExceptionHandling
       Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging
       Microsoft.Practices.EnterpriseLibrary.Logging
       Microsoft.Practices.ObjectBuilder2

       下面开始配置：


       1.在我们的ASP.NET项目的web.config文件上点击右键，就会弹出"Edit Enterprise Library Configuration"选项。点击后就会看见如下界面：

 

 


       2.在弹出的界面中选中"web.config"，点击右键 "新建"－"Logging Application Block",这样就把添加了日志记录的模块的节点，如下：
       

 

 

       3.在默认情况下，在event log 的 trace listener节点有一个Trace Listeners，因为我们要发送Email，所以要添加个e-mail trace listener。在Trace Listeners点击右键，"新建"－"Email Trace Listener",之后就添加了"Email TraceListener"节点，然后选中"Email TraceListener"，查看属性，可以设置发送Email的设置。如图：

      


 

 

             并且设置Formatter属性并且选择"Text Formatter"，设置信息格式为文本的形式。
 
       4.现在点击"web.config"添加异常handler。"新建"－"Exception Handling Application Block",如下：
 


 
       然后在"Exception Handling Application Block"上右击"新建"－"Exception Policy",然后我们可以重新命名为"MyPolicy".然后在"MyPolicy"上右键，选中"New Exception Type",然后选择我们要处理的异常，如图：


 
       我们一般是选择默认设置：处理所有异常。

 

       好了，现在我们把事件的处理程序也添加了，那么下面就要加类似于"rules"的设置。
 
       5.在"Exception"节点上右击"新建"-"Logging Handler",然后选择"Logging Handler"节点，并且展开，选中"FormatterType"，展开并且选"TextExceptionFormatter",最后确认就OK了。如下：
 
////

 

       6.然后在点击"Logging Application Block\Special Source\All Events"的那个节点，右击"新建"－"Trace Listener Reference"添加"Trace Listener Reference",并且设置"ReferencedTrace Listener"属性为"Email Trace Listener"，最后保存就行了。

       7.我们在Global.asax文件下添加引用：
       

<%@ Import Namespace=”Microsoft.Practices.EnterpriseLibrary.ExceptionHandling” %>


       添加代码：
 

void Application_Error(object sender, EventArgs e)
 {
  // Code that runs when an unhandled error occurs
  ExceptionPolicy.HandleException(Server.GetLastError(), “Global Policy”);
 }
复制代码


 

posted @ 2011-12-14 13:19  火腿骑士  阅读(242)  评论(0)  编辑  收藏  举报