错误处理规范

　　一、整体规范

　　1.按照错误类型，通常的处理方式如下：

　　3.按照展现方式，通常的分类如下：

　　原则

　　异常应该是分层的

　　异常应该集中处理

　　异常定义

　　每个模块应该有自己的应用程序异常类型层次，从本模块主动抛出的应用程序异常都应该属于该异常类型层次，客户代码可以只捕捉该层次的基类(?)

　　应用程序的所有自定义异常都应该从开发平台提供的“应用程序异常基类”派生

　　中间件等平台程序的运行时异常都应该从开发平台提供的“运行时异常基类”派生(?)

　　中间件等平台程序的运行时错误都应该从开发平台提供的“错误基类”派生(?)

　　异常捕获

　　对有能力处理的异常，捕获并处理之

　　在调用的中间层，对未知异常保持沉默

　　在调用的最高层，必须捕获所有异常，避免本身进程或宿主进程崩溃

　　记录捕获到的每个原始异常的信息

　　异常抛出

　　每个模块应使用本模块所能得知的最精确的错误原因报告异常信息

　　如果有原始异常，在重新抛出的自定义异常中附加原始异常的信息

　　三、几点说明

　　错误处理与日志系统

　　错误处理不等同于日志系统，日志系统只是错误信息的一种记录手段

　　错误信息的输出应全部调用日志系统来完成

　　程序员错误与运行时错误

　　接口函数的前置条件，应该是一种规范，是客户程序员必须遵守的约定;客户程序员违反了约定，程序将产生异常或不可预知的错误;对于这类约定，不应该需要有运行时的代码检查 ;比如如果你的接口函数的一个参数不能为null，而你在函数开始部分程序里写：

　　if(xxx == null){

　　throw new someException();

　　}

　　你的代码实际上允许该参数为null，因为你对null的情况进行了运行时处理;尽管你在文档里声明该参数不能为null，但如果客户程序员遵守了约定，那么你这段检查代码就是冗余的

　　当你对参数没有任何检查就进行了使用，而非法的参数值导致了错误，此时有两种情况： 如果你在接口函数说明里列出了参数不允许的非法取值，那么客户程序员应该修改程序避免传入非法值，该类错误称为程序员错误;如果你没有说明，那么你应该修改函数，处理非法参数

　　不是所有的限制条件在文档里说明一下，就可以把责任扔给客户程序员了，有一些错误必须处理：特别是客户程序员不需要import你的package就可以和你的接口交互的情况，如socket服务器 ，你必须在socket服务程序内部检查所有接收到的数据，拒绝错误的请求，否则极易遭到攻击

　　错误代码与异常

　　不应该使用bool值来返回成功与否，bool返回值只应用在真正查询bool状态的操作中，如 bool IsDirty()，bool hasNext()等

　　整形或bool型的错误代码返回值强迫客户程序员检查每一次调用，应用异常取代之

　　四、附录

　　Anders Hejlsberg谈C#异常设计

　　译者注：在写一段程序时，如果没有用try-catch捕捉异常或者显式的抛出异常，而希望程序自动抛出，一些语言的编译器不会允许编译通过，如Java就是这样。这就是Checked Exceptions最基本的意思。该特性的目的是保证程序的安全性和健壮性。Zee&Snakey(MVP)对此有一段很形象的话，可以参见http://www.blogcn.com/user2/zee/main.asp。Bruce Eckel 也有相关的一篇文章:《Does Java need Checked Exceptions》，参见http://www.mindview.net/Etc/Discussions/CheckedExceptions

　　对Checked Exceptions特性持保留态度

Bill Venners	你提到过Checked Exceptions的扩展性和版本相关性这两个问题。现在能具体解释一下它们的意思么？
Anders Hejlsberg	让我首先谈谈版本相关性，这个问题更容易理解。假设我创建了一个方法foo，并声明它可能抛出A、B、C三个异常。在新版的foo中，我要增加一些功能，由此可能需要抛出异常D。这将产生了一个极具破坏性的改变，因为原来调用此方法时几乎不可能处理过D异常。     也就是说，在新版本中增加抛出的异常时，给用户的代码带来了破坏。在接口中使用方法时也有类似的问题。一个实现特定功能的接口一经发布，就是不可改变的，新功能只能在新版的接口中增加。换句话说，就是只能创建新的接口。在新版本中，你只有两种选择，要么建立一个新的方法foo2，foo2可以抛出更多的异常，要么在新的foo中捕获异常D，并转化为原来的异常A、B或者C。
Bill Venners	但即使在没有Checked Exceptions特性的语言中，（增加新的异常）不是同样会对程序造成破坏么？假如新版foo抛出了需要用户处理的新的异常，难道仅仅因为用户不希望这个异常发生，他写代码时就可以置之不理吗？
Anders Hejlsberg	不，因为在很多情况下，用户根本就不关心（异常）。他们不会处理任何异常。其实消息循环中存在一个最终的异常处理者，它会显示一个对话框提示你程序运行出错。程序员在任何地方都可以使用try finally来保护自己的代码，即使运行时发生了异常，程序依然可以正确运行。对于异常本身的处理，事实上，程序员是不关心的。 很多语言的throws语法（如Java），没必要地强迫你去处理异常，也就是逼迫你搞清楚每一个异常的来源。它们要求你要么捕获声明的异常，要么将它们放入throws语句。程序员为了达到这个要求，做了很多荒谬可笑的事情。例如他们在声明每个方法时，都必须加上修饰语：“throws Exception”。这完全是在搧这个特性的耳光，它不过是要求程序员多作些官样文章，对谁都没有好处
Bill Venners	如此说来，你认为不要求程序员明确的处理每个异常的做法，在现实中要适用得多了？
Anders Hejlsberg	人们为什么认为（显式的）异常处理非常重要呢？这太可笑了。它根本就不重要。在我印象中，一个写得非常好的程序里，try finally和try catch语句数目大概是10：1。在C#中，也可以使用和类似try finally的using语句（来处理异常）
Bill Venners	finally到底干了些什么？
Anders Hejlsberg	finally保证你不被异常干扰，但它不直接处理异常。异常处理应该放在别的什么地方。实际上，在任何一个事件驱动的（如现代图形界面）程序中，在主消息循环里，都有一个缺省的异常处理过程，程序员只需要处理那些没被缺省处理的异常。但你必须确保任何异常情况下，原来分配的资源都能被销毁。这样一来，你的程序就是可持续运行的。你肯定不希望写程序时，在100个地方都要处理异常并弹出对话框吧。如果那样的话，你作修改时就要倒大霉了。异常应该集中处理，并在异常来临处保护好你的代码

Checked Exceptions的扩展性

Bill Venners

那么Checked Exceptions的扩展性又是如何呢？

Anders Hejlsberg

扩展性有时候和版本性是相关的。 在一个小程序里，Checked Exceptions显得蛮迷人的。你可以捕捉FileNotFoundException异常并显示出来，是不是很有趣？这在调用单个的API时也挺美妙的。但是在开发大系统时，灾难就降临了。你计划包含4、5个子系统，每个子系统抛出4到10个异常。但是（实际开发时），你每在系统集成的梯子上爬一级，必须被处理的新异常都将呈指数增长。最后，可能每个子系统需要抛出40个异常。将两个子系统集成时，你将必须写80个throw语句。最后，可能你都无法控制了。 很多时候，Checked Exceptions都会激怒程序员，于是程序员就想办法绕过这个特性。他要么在到处都是写“throws Exception”，要么——我都不知道自己看到多少回了——写“try, da da da da da(译者注：意思是飞快的写一段代码), catch curly curly(译者注：即‘{ }’)”，然后说：“哦，我会回头来处理这些空的异常处理语句的。”实际上，理所当然的没有任何人会回头干这些事情。这时候，Checked Exceptions已经造成系统质量的极大下降。 所以，你可能很重视这些问题，但是在我们决定是否将Checked Exceptions的一些机制放入C#时，却是颇费了一番思量的。当然，知道什么异常可能在程序中抛出还是有相当价值的，有一些工具也可以作这方面的检查。我不认为我们可以建立一套足够严格而严谨的规则（来完成异常检查），因为（异常）还可能是编译器的错误引起的呢。但是我认为可以在（程序）分析工具上下些功夫，检测是否有可疑代码，是否有未捕获的异常，并将这些隐藏的漏洞给你指出来

原文转自：http://www.ltesting.net