NET中异常处理最佳实践.doc

.NET中异常处理最佳实践 ? 简介 “我的软件从来不出错”你能相信吗？我几乎听到你们全部尖叫说我是个说慌者。“从不出错的软件从某种程度上讲是不可能的！”????和普通人的观念相反，创造可信赖的，健壮的软件并不是一件不可能的事情。请注意，我并没有提及意欲控制核电站的无漏洞软件。我提到的仅仅是可以在无人看管的服务器或者客户端机器上运行的普通的商业软件，在长时间(几个星期或是几个月)可以无重大故障的工作。可预测的，我的意思是它拥有低出错率，你可以迅速理解出错原因然后快速搞定它，同是，它从不因为外部错误而毁坏数据。换句话说，软件是稳定的。软件中有漏洞是可以原谅的，甚至是被期望的。不可原谅的是您无法解决一个复发的漏洞，仅仅是因为您没用足够的信息。????为了更好的理解我所说的，我看过不计其数的商业软件，DBMS是这样报告空间不足的错误的：“不能更新用户操作，请与系统管理员联系后在尝试。”????虽然，用这则消息向一个商业用户报告一种未知的资源失败也许是恰当的，通常它应该是可以用来调试错误原因的全部调试信息。但是，如果没用东西被记入日志，了解当时的状况将会是一件非常费时的事情，通常，程序员会猜测许多可能的原因直到他们找到真正的错误。? 在这篇文章中注意到这些，我将会集中精力介绍如何去更好的利用.NET的异常机制：我不会去讨论怎样正确的报告错误信息，因为我认为这个问题应该属于UI(用户界面)领域，同时它十分依赖正在开发的接口和所要面对的听众；一面向青少年的博客文章编辑者应该用一种与直接面向编程人员的socket server完全不同的方式来报告出错信息。 做好最坏的打算???几个基础设计概念将会使你的程序更加健壮，同时提高用户处理意外错误的经验。“提高用户处理意外错误的经验”是什么意思呢？它是用户不会被你提供的令人惊异的对话框吓的发抖。它更多的是不要使用户误用数据，搞垮计算机，以确保计算机运转的更加安全。如果你的程序可以无损坏的处理空间不足错误，你将会增加用户的经验。(?及早检查 强大的类型检查和确认是防止意外异常，确保文档记录及代码检查的有力工具。发现问题的杀伤力越早，这个问题就越容易解决。设法在数月后去了解InvoiceItems 表中Customerid在Productid栏目中的作用几乎是不可能的，这不是开玩笑。如果你使用类而不是原始数据类型（比如 int ,string 等）来存储客户数据，编译器将不会给你处理上述事件的机会。(?不要相信外部数据 外部数据是不可相信的。不管这些数据是来自寄存器，数据库，硬盘，socket，你所书写的文件抑或是键盘，它们都必须被广泛的检查。所有的外部数据都应该被检查，只有这样你才可以信任它。我经常发现信任配置文件的程序，原因是它们的编写者从没想过有人会编辑或误用它。(唯一可信赖的外部设施是：显示器，鼠标和键盘 当你需要外部数据时，你可能遇到以下的情形： ◆没有足够的安全权限◆信息不在那儿◆信息不完整◆信息是完整的但是不可用的 不管它是注册信息，文件，SOCKET,数据库，网站服务抑或是串行端口，所有的外部数据源迟早都会出错。为安全错误做好准备才能把损失降到最小。(?书写同样可能出错 不可靠的数据源同样是不可靠的数据仓库。当你保存数据时，类似的情况可能发生： ◆没有足够的安全权限◆设备不在那儿◆设备没有足够的空间◆设备由物理错误 以下便是压缩程序开始时创建临时文件，压缩完后重命名它而不是取代原来文件的原因：如果硬盘（或压缩软件）因某种原因出错，你将会丢失你的原始数据。 代码的安全性 我的一个好朋友经常说：“一个好的程序员从不在他的项目中引用不安全的代码”。我不认为这是一个好的程序员的全部，但是的确几乎是这样。下面，我编译了一些常见的“不安全代码”，这些代码在经过异常处理后可以引用到你的项目中。 不要抛出new Exception() 不要抛出 new Exception()。Exception是一个非常大的类，如果没有side-effect，很难去捕获。引用你自己的异常类，但是使它继承自AppliationException。通过这种方法，你可以设计一个专门的异常捕获程序去捕获框架抛出的异常，同时设计另一个异常捕获程序来处理自己抛出的异常。 修订记录：在以下的评论部分中，David Levitt写信告诉我说，尽管Microsoft公司在MSDN doc中依然鼓吹使用System.ApplicationException做为基础类，但这已经不是一个好的习惯，就像Brad Adams在他的博客中所说的那样。这个方法是尽可能创造浅且宽泛的异常类层次，就像你经常处理类层次结构那样。我不马上改变文章内容的原因是在此介绍之前，我需要做更多的研究。做完这项研究