错误处理(Error-Handling)：为何、何时、如何(rev#2)
By 刘未鹏(pongba)
C++的罗浮宫(http://blog.csdn.net/pongba)
TopLanguage(http://groups.google.com/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)。读入整型失败是很常见的情况，而且，这里的“读入整型失败”其实真正的含义是“流的下一个字段不是整型”，后者很明确地不代表一个错误；再比如在一个字符串中寻找一个子串，如果找不到该子串，也不算错误。这类控制程序流的返回值都有一个共同的特点，即我们都一定会利用它们的返回值来编写if-else，循环等控制结构，如：
if(foo(…)) { … }
else { … }
或
while(foo(…)) { … }
这里再摘两个相应的具体例子，一个来自Gosling的《The Java Programming Language》，是关于stream的。
使用status-code：
while ((token = stream.next()) != Stream.END)
process(token);
stream.close();
使用exception：
try {
for(;;) {
process(stream.next());
}
} catch (StreamEndException e) {
stream.close();
}
高下立判。
另一个例子来自TC++PL（Well, not exactly）：
size_t index;
try {
index = find(str, sub_str);
… // case 1
} catch (ElementNotFoundException& e) {
… // case 2
}
使用status-code：
int index = find(str, sub_str)
if(index != -1) {
… // case 1
} else {
… // case 2
}
以上这类情况的特点是，返回值本身也是程序主逻辑（happy path）的一部分，返回的两种或几种可能性，都是完全正常的、预料之中的。
这类错误如何处理后面会讨论。
2. 编程bug不是错误。属于同一个人维护的代码，或者同一个小组维护的代码，如果里面出现bug，使得一个函数的precondition得不到满足，那么不应该视为错误。而应该用assert来对付。因为编程bug发生时，你不会希望栈回滚，而是希望程序在assert失败点上直接中断，调用调试程序，查看中断点的程序状态，从而解决代码中的bug。
关于这一点，需要尤其注意的是，它的前提是：必须要是同一个人或小组维护的代码。同一个小组内可以保证查看到源代码，进行debug。如果调用方和被调用方不属于同一负责人，则不能满足precondition的话就应该抛出异常。总之记住一个精神：assert是用来辅助debug的（assert的另一个作用是文档，描述程序在特定点上的状态，即便assert被关闭，这个描述功能也依然很重要）。
注意，有时候，为了效率原因，也会在第三方库里面使用assert而不用异常来报告违反precondition。比如strcpy，std::vector的operator[]。
3. 频繁出现的不是错误。频繁出现的情况有两种可能，一是你的程序问题大了（不然怎么总是出错呢？）。二是出现的根本不是错误，而是属于程序的正常流程。后者应该改用status-code。
插曲：异常（exception）vs错误代码（error-code）
异常相较于错误代码的优势太多了，以下是一个（不完全）列表。
异常与错误代码的本质区别之一——异常会自动往上层栈传播：一旦异常被抛出，执行流就立即中止，取而代之的是自动的stack-unwinding操作，直到找到一个适当的catch子句。
相较之下，使用error-code的话，要将下层调用发生的错误传播到上层去，就必须手动检查每个调用边界，任何错误，都必须手动转发（返回）给上层，稍有遗漏，就会带着错误的状态继续往下执行，从而在下游不知道离了多远的地方最终引爆程序。这来了以下几个问题：
1. 麻烦。每一个可能返回错误代码的调用边界都需要检查，不管你实际上对不对返回的错误作响应，因为即便你自己不解决返回的错误，也要把它传播到上层去好让上层解决。
2. 不优雅且不可伸缩(scalability)的代码（错误处理代码跟One True Path（也叫happy path）搅和在一起）。关于这一条普遍的论述都不够明确，比如有人可能会反驳说，那错误反正是要检查的，用异常难道就不需要捕获异常了吗？当然是需要的，但关键是，有时候我们不一定会在异常发生的立即点上捕获并处理异常。这时候，异常的优势就显现出来了，比如：
void foo()
{
try {
op1;
op2;
…
opN;
} catch (…) {
… // log
… // clean up
throw;
}
}
如果用error-code的话：
int foo()
{
if(!op1()) {
… // log? clean up?
return FAILED;
}
if(!op2()) {
… // log? clean up?
return FAILED;
}
…
return SUCCEEDED;
}
好一点的是这样：
int foo()
{
if(!op1()) goto FAILED;
if(!op2()) goto FAILED;
…
if(!opN()) goto FAILED;
return SUCCEEDED;
FAILED:
… // log, clean up
return FAILED;
}
就算是最后一种做法（所谓的“On Error Goto”），One True Path中仍然夹杂着大量的噪音（如果返回的错误值不只是FAILED/SUCCEEDED两种的话噪音会更大）。此外手动检查返回值的成功失败毕竟是很error-prone的做法。
值得注意的是，这里我并没有用一个常被引用的例子，即：如果你是用C写代码（C不支持局部变量自动析构（RAII）），那么程序往往会被写成这样：
int f()
{
int returnCode = FAILED;
acquire resource1;
if(resource1 is acquired) {
acquire resource2;
if(resource2 is acquired) {
acquire resource3;
if(resource3 is acquired) {
if(doSomething1()) {
if(doSomething2()) {
if(doSomething3()) {
returnCode = SUCCEEDED;
}
}
}
release resource3;
}
release resource2;
}
release resource1;
}
return returnCode;
}
或者像这样：
int f()
{
int returnCode = FAILED;
acquire resource1;
if(resources1 is not acquired)
return FAILED;
acquire resource2;
if(resource2 is not acquired) {
release resource1;
return FAILED;
}
acquire resource3;
if(resource3 is not acquired) {
release resource2;
release resource1;
return FAILED;
}
... // do something
release resource3;
release resource2;
release resource1;
return SUCCEEDED;
}
（一个更复杂的具体例子可以参考[16]）
以上两种方案在可伸缩性方面的问题是显而易见的：一旦需要获取的资源多了以后代码也会随着越来越难以卒读，要么是if嵌套层次随之线性增多，要么是重复代码增多。所以即便项目中因为某些现实原因只能使用error-code，也最好采用前面提到的“On Error Goto”方案。
另一方面，当整个函数需要保持异常中立的时候，异常的优势就更显现出来了：使用error-code，你还是需要一次次的小心check每个返回的错误值，从而阻止执行流带着错误往下继续执行。用异常的话，可以直接书写One True Path，连try-catch都不要。
当然，即便是使用异常作为错误汇报机制，错误安全（error-safety）还是需要保证的。值得注意的是，错误安全性属于错误处理的本质困难，跟使用异常还是error-code来汇报错误没有关系，一个常见的谬误就是许多人把在异常使用过程中遇到的错误安全性方面的困难归咎到异常身上。
3. 脆弱（易错）。只要忘了检查任意一个错误代码，执行流就必然会带着错误状态往下继续执行，后者几乎肯定不是你想要的。带着错误状态往下执行好一点的会立即崩溃，差一点的则在相差十万八千里的地方引发一个莫名其妙的错误。
4. 难以（编写时）确保和（review时）检查代码的正确性。需要检查所有可能的错误代码有没有都被妥善check了，其中也许大部分都是不能直接对付而需要传播给上级的错误。
5. 耦合。即便你的函数是一个异常中立的函数，不管底层传上来哪些错误一律抛给上层，你仍然需要在每个调用的边界检查，并妥善往上手动传播每一个错误代码。而一旦底层接口增加、减少或改动错误代码的话，你的函数就需要立即作出相应改动，检查并传播底层接口改动后相应的错误代码——这是很不幸的，因为你的函数只是想保持异常中立，不管底层出什么错一律抛给上层调用方，这种情况下理想情况应该是不管底层的错误语意如何修改，当前层都应该不需要改动才对。
6. 没有异常，根本无法编写泛型组件。泛型组件根本不知道底层会出哪些错，泛型组件的特点之一便是错误中立。但用error-code的话，怎么做到错误中立？泛型组件该如何检查，检查哪些底层错误？唯一的办法就是让所有的底层错误都