.Net 下未捕获异常的处理 作者:Eaglet cnblogs/eaglet/archive/2009/02/17/1392191.html 随着.Net 技术的发展,.Net 技术被逐渐应用到很多大型的应用软件项目中。这些项目的规模越来 越大,很多项目中除了自己的代码外还引用了很多第三方的.net 组件。同时很多项目又被应用到很多关 键的部门,
软件系统的稳定性越来越至关重要。由于.Net 框架提供了非常强大的异常处理机制,同时对 一些非托管代码很难控制的系统问题比如指针越界,内存泄漏等提供了很好的解决
方案。相比非托管代码 构建的系统,.Net 构建的系统更加稳定。不过这并不是说.Net 构建的系统就完全无懈可击,很多由于代 码的不严谨或者
系统问题引发的故障将会导致.Net 应用程序产生未捕获异常,从而导致应用程序异常终 止。本文将对三种最常见的.Net 应用的未捕获异常处理进行阐述。 在开始本文之前,让我们来看看.Net 在什么情况下会产生未捕获异常。未捕获异常从定义上说就是 结构化异常处理未能捕获的异常。 通俗的讲就是发生在 Try Catch 块意外的异常。 那么是不是我们在 Main 函数中加一个 Try Catch 块就可以捕获全部未捕获异常了呢?答案是否定的。这里面有两种情况无法通 过这种方法捕获: 1. GC 产生的异常,这种异常通常因为 Finalize 函数中引发未捕获异常引起。当然这并不绝对,一些系 统
问题比如内存耗尽有时候也会造成 GC 异常。 2. 主线程以为的线程引发的未捕获异常。 这些异常我们往往可以在线程的主函数中用 Try Catch 来捕获, 但如果系统中使用了外部的组件,或者甚至是.Net 框架自带的一些系统组件,由这些组件的线程引发的 异常,调用代码无法通过 Try Catch 来捕获。 从上面两点来看, 即使我们的代码在每个地方都加了 Try Catch , 也不能百分百杜绝未捕获异常的发生。 鉴于此,为了提高系统的健壮性和可维护性,我们需要通过一种方法来截获这些未捕获异常,并进行适当 的处理。 .Net 的
设计者已经考虑到这些问题,并且为我们提供了一个叫 UnhandledExceptionEventHandler 的事件,通过这个事件,我们可以截获未捕获异常,并进行处理。 这个事件的事件参数 UnhandledExceptionEventArgs e, 有两个属性,一个是 ExceptionObject, 这个属性返回为截获异常的对象实例。还有一个属性是 IsTerminating,这个属性告诉我们这个异常是 否会导致应用终止。 这里需要说明的是, 对于.Net1.1 和 .Net2.0 及以上, 情况是不一样的, .Net1.1 只 有在主线程中的未捕获异常才会终止应用程序,而.Net2.0 及以上版本则是始终终止应用程序。如果不终 止应用程序, 而是有 CLR 将当前异常消化, 系
统的运行状态很可能不可控, 最后可能会发生更大的故障, 所以.Net2.0 以后,对于所有未捕获异常,一律终止当前应用。这样看来,对于.net2.0 以上的应用似乎 我们截获未捕获异常已经毫无意义,其实不然。通过截获为未捕获异常,我们可以记录下程序是再哪里产 生这种未捕获异常的,以便程序的开发者改进程序。我们也可以在当前应用退出前为系统做一些其他的保 护
工作,比如备份数据,告警提示等等。 下面我们来看看三种常见的.Net 应用分别如何来截获未捕获异常。
? 控制台应用
首先为当前 AppDomain 添加 UnhandledExceptionEventHandler
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(UnhandledExceptionEv entHandler);
再添加事件响应函数
static void UnhandledExceptionEventHandler(object sender, U nhandledExceptionEventArgs e) { try {
using (System.IO.FileStream fs = new System.IO.File Stream(@"c:\testme.log", System.IO.FileMode.Append, System.IO.FileAc cess.Write)) {
using (System.IO.StreamWriter w = new System