项目开发经验-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告诉开发人员出现了什么问题,如下
Code 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 />节点:
默认情况下是禁用的,我们启用就应该如下:
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 >
这样就行了。
六 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节点类似。
下面的节点,看起来很吓人的,其实是声明异常信息以什么格式记录:
Code <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节点类似:
Code <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”); } 就行了,强大异常处理就成功了。
今天到这里,谢谢!
原文链接: