ASP.NET项目开发中的异常处理
2013-05-04 11:01
471 查看
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>
这样就行了。
前言:异常的处理在项目开发中是很有必要的,异常的处理不仅仅只是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>
这样就行了。
相关文章推荐
- ASP.NET项目开发中的异常处理
- 项目开发经验-ASP.NET项目开发中的异常处理
- 项目开发经验-ASP.NET项目开发中的异常处理
- 项目开发-ASP.NET项目开发中的异常处理
- ASP.NET项目开发中的异常处理
- 项目开发经验-ASP.NET项目开发中的异常处理
- 项目开发经验-ASP.NET项目开发中的异常处理
- 用VSCode开发一个asp.net core 2.0+angular 5项目(4): Angular5全局错误处理
- 基于.Net Framework 4.0 Web API开发(3):ASP.NET Web APIs 异常的统一处理Attribute 和统一写Log 的Attribute的实现
- 在ASP.NET项目中建立统一的异常处理机制
- 项目开发中的一些注意事项以及技巧总结 基于Repository模式设计项目架构—你可以参考的项目架构设计 Asp.Net Core中使用RSA加密 EF Core中的多对多映射如何实现? asp.net core下的如何给网站做安全设置 获取服务端https证书 Js异常捕获
- [原创]在ASP.NET项目中建立统一的异常处理机制
- asp.net访问access 发生了未处理的异常 "操作必须使用一个可更新的查询"错误
- ASP.NET未处理异常的处理
- 整理asp.net开发中几种常见公共捕获异常方式
- ASP.Net项目出错处理方法汇总!
- ASP.NET全局错误处理和异常日志记录以及IIS配置自定义错误页面
- LBPL--基于Asp.net、 quartz.net 快速开发定时服务的插件化项目
- Asp.NET大文件上传组件开发总结(三)---处理文件内容
- Asp.net MVC 之异常处理