错误处理(Error-Handling)：为何、何时、如何(rev#2).docVIP

错误处理(Error-Handling)：为何、何时、如何(rev#2) 错误处理(Error-Handling)：为何、何时、如何(rev#2) By 刘未鹏(pongba) C++的罗浮宫(/pongba) TopLanguage(/group/pongba) 引言 错误处理（Error-Handling）这个重要议题从1997年（也许更早）到2004年左右一直是一个被广泛争论的话题，曾在新闻组上、博客上、论坛上引发口水无数（不亚于语言之争），Bjarne Stroustrup、James Gosling、Anders Hejlsberg、Bruce Eckel、Joel Spolsky、Herb Sutter、Andrei Alexandrescu、Brad Abrams、Raymond Chen、David Abrahams…，各路神仙纷纷出动，好不热闹:-) 如今争论虽然已经基本结束并结果；只不过结论散落在大量文献当中，且新旧文献陈杂，如果随便翻看其中的几篇乃至几十篇的话都难免管中窥豹。就连Gosling本人写的《The Java Programming Language》中也语焉不详。所以，写这篇文章的目的便是要对这个问题提供一个整体视图，相信我，这是个有趣的话题:-) 为什么要错误处理？ 这是关于错误处理的问题里面最简单的一个。答案也很简单：现实世界是不完美的，意料之外的事情时有发生。 一个现实项目不像在学校里面完成大作业，只要考虑该完成的功能，走happy path（也叫One True Path）即可，忽略任何可能出错的因素（呃.. 你会说，怎么会出错呢？配置文件肯定在那，矩阵文件里面肯定含的是有效数字.. 因为所有的环境因素都在你的控制之下。就算出现什么不测，比如运行到一半被人拔了网线，那就让程序崩溃好了，再双击一下不就行了嘛）。 然而现实世界的软件就必须考虑错误处理了。如果一个错误是能够恢复的，要尽量恢复。如果是不能恢复的，要妥善的退出模块，保护用户数据，清理资源。如果有必要的话应该记录日志，或重启模块等等。 简而言之，错误处理的最主要目的是为了构造健壮系统。 什么时候做错误处理？（或者：什么是“错误”？） 错误，很简单，就是不正确的事情。也就是不该发生的事情。有一个很好的办法可以找出哪些情况是错误。首先就当自己是在一个完美环境下编程的，一切precondition都满足：文件存在那里，文件没被破坏，网络永远完好，数据包永远完整，程序员永远不会拿脑袋去打苍蝇，等等… 这种情况下编写的程序也被称为happy path（或One True Path）。 剩下的所有情况都可以看作是错误。即“不应该”发生的情况，不在算计之内的情况，或者预料之外的情况，whatever。 简而言之，什么错误呢？调用方违反被调用函数的precondition、或一个函数无法维持其理应维持的invariants、或一个函数无法满足它所调用的其它函数的precondition、或一个函数无法保证其退出时的postcondition；以上所有情况都属于错误。（详见《C++ Coding Standards: 101 Rules, Guidelines, and Best Practices》第70章，或《Object Oriented Software Construction, 2nd edition》第11、12章） 例如文件找不到（通常意味着一个错误）、配置文件语法错误、将一个值赋给一个总应该是正值的变量、文件存在但由于访问限制而不能打开，或打开不能写、网络传输错误、网络中断、数据库连接错误、参数无效等。 不过话说回来，现实世界中，错误与非错误之间的界定其实是很模糊的。例如文件缺失，可能大多数情况下都意味着一个错误（影响程序正常执行并得出正常结果），然而有的情况下也可能根本就不是错误（或者至少是可恢复的错误），比如你的街机模拟器的配置文件缺失了，一般程序只要创建一个缺省的即可。 因此，关于把哪些情况界定为错误，具体的答案几乎总是视具体情况而定的。但话虽如此，仍然还是有一些一般性的原则，如下： 哪些情况不属于错误？ 1. 控制程序流的返回值不是错误：如果一个情况经常发生，往往意味着它是用来控制程序流程的，应该用status-code返回（注意，不同于error-code），比如经典的while(cin i)。读入整型失败是很常见的情况，而且，这里的“读入整型失败”其实真正的含义是“流的下一个字段不是整型”，后者很明确地不代表一个错误；再比如在一个字符串中寻找一个子串，如果找不到该子串，也不算错误。这类控制程序流的返回值都有一个共同的特点，即我们都一定会利用它们的返回值