错误码还是异常

前几天拿到了一份C语言写的程序，需要把它改成动态链接库嵌入我的程序。但是程序里遇到异常以后都是打印异常信息就直接调用exit退出程序了，我需要把异常抛出给上层进行异常处理，不直接终止程序。使用托管语言的Exception是最方便的，但是C语言程序没有GC，也不是想象中的那么方便，抛异常前还得注意释放资源。错误码就需要每一层，每个方法都得改动，比较麻烦。

1.错误码

错误码缺点：

1) 默认是可以忽略的，因为调用函数时可以不处理其返回值，从而错误处理要依赖于程序员的主动性，而不是程序机制的要求；
2) 不能跨作用域传送，必须逐层向上转发，即使中间没有对错误码进行重新定义；

2.异常

异常用于处理正确程序中的运行期问题(比如内存分配失败，窗口创建失败，线程创建失败，打开文件失败)，以尽可能恢复，而不是终止程序。

异常优点：

1) 异常默认是不可忽略的，抛出的异常必须捕获，否则就会报错；
2) 异常可以跨作用域传送，从而错误的发现和处理被很好地分离开来；

断言（Assert）

仅在Debug版本起作用，Release版本一般不会把断言编译进去。C语言assert和C#的Debug类都是条件编译。
断言的意思是在编码正确的情况下不会出现某种情况，一旦断言失败就意味着该修改代码了。

讨论

一个现实的程序离不开错误处理。错误处理使用异常还是错误码，这是一个方法论的问题。方法论的问题都是可以扯皮的。事实上，某个时期这两者之争不亚于语言之争。公说公有理婆说婆有理。现在我只想说说我的几点认识，自认为还是比较中肯的：
1）不用异常可以写出很健壮的程序，c里面没有异常，很多c写的程序十分地健壮。
2）使用异常可以写出很健壮的程序，java基本上都是靠异常来错误处理，很多java写的服务器十分健壮。
3）使用错误码，却不进行必要地判断，这样的程序会有很大问题，而且也许发现工作异常的位置离异常发生点有一段距离了，增加了抓虫的难度。
4）使用异常，却不捕获异常，对于命令式的程序如rmdir，没啥问题。但对服务器，尤其是要求24*365工作的程序，是不可接受的。
5）使用异常比使用错误码，编写库函数更容易。
6）使用基于异常的库和基于错误码的库。如果应用程序需要就近吞掉每个异常，则前者更麻烦些（判断返回码比try、catch简洁些）。但如果有总的错误处理函数，异常显然更简单。异常有利于错误的集中处理。

我个人认为异常更为方便有效，异常机制出现的时间比错误码晚得多，之后却占据了更重要的地位，肯定有其优势。使用异常有以下几点注意：
1）不要用异常来返回非错误信息（如果一个函数经常会异常，可能就是违反了该条例）：比如一个查找函数，找不到对象的时候扔异常，这一般是不合理的。应该用返回值来表示是否查找成功，当发生文件IO失败或者网络IO失败时才扔异常。
2）不要用异常来返回编程bug，而是用assert。这是很有意义的：假设使用assert来判断一个函数的输入是否合理。如果程序中存在bug，程序员调试的时候可能可以发现，然后进行修改。如果不幸bug比较隐蔽，程序上线了，这时候assert被忽略了，当函数输入非法时程序也不会挂掉。
3）对于一定不能挂掉的线程，主体结构如下：
while(!exit_flag){
try {//do sth }
catch(exception e){//print log or other}
catch(…){//print log or other}
}
4) 当扔异常时，应该尽量保证不影响所属对象的状态一致性，以便下次执行同样代码时不会产生问题。事实上，这对于错误码也是一样的。如果前面的工作会影响到对象的状态，不恢复这些状态，直接返回错误码，这也是不行的。不过如果引入前提：一旦错误，该对象就不可用了。那就不用考虑太多了。比如对于文件IO对象来说，这种假设一般没问题。

我的内容就说到这边，现在转载一篇好文章：（发现太长了，黏贴不进来，就贴个开头，自己google去吧）

错误处理(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）的一部分，返回的两种或几种可能性，都是完全正常的、预料之中的。

1’. 另一方面，还有一种情况与此有微妙的区别， 即“可恢复错误”。可恢复错误与上面的情况的区别在于它虽说也是预料之中的，但它一旦发生程序往往就会转入一个错误恢复子过程，后者会尽可能恢复程序主干 执行所需要的某些条件，恢复成功程序则再次转入主干执行，而一旦恢复失败的话就真的成了一个货真价实的让人只能干瞪眼的错误了。比如C++里面的operator new如果失败的话会尝试调用一个可自定义的错误恢复子过程，当然，后者并非总能成功将程序恢复过来。除了转入一个错误恢复子过程之外，另一种可能性是程序会degenerate入一条second-class的支流，后者也许能完成某些预期的功能，但却是“不完美”地完成的。

这类错误如何处理后面会讨论。

1. 编程bug不是错误。属于同一个人维护的代码，或者同一个小组维护的代码，如果里面出现bug，使得一个函数的precondition得不到满足，那么不应该视为错误。而应该用assert来对付。因为编程bug发生时，你不会希望栈回滚，而是希望程序在assert失败点上直接中断，调用调试程序，查看中断点的程序状态，从而解决代码中的bug。

关于这一点，需要尤其注意的是，它的前提是：必须要是同一个人或小组维护的代码。同一个小组内可以保证查看到源代码，进行debug。如果调用方和被调用方不属于同一负责人，则不能满足precondition的话就应该抛出异常。总之记住一个精神：assert是用来辅助debug的（assert的另一个作用是文档，描述程序在特定点上的状态，即便assert被关闭，这个描述功能也依然很重要）。

注意，有时候，为了效率原因，也会在第三方库里面使用assert而不用异常来报告违反precondition。比如strcpy，std::vector的operator[]。

1. 频繁出现的不是错误。频繁出现的情况有两种可能，一是你的程序问题大了（不然怎么总是出错呢？）。二是出现的根本不是错误，而是属于程序的正常流程。后者应该改用status-code。
   ————————————————
   版权声明：本文为CSDN博主「Runyon1982」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
   原文链接：https://blog.csdn.net/runyon1982/java/article/details/49018525