代替 try / catch / throw 的通常做法是返回一个返回代码（有时称为错误代码），例如，printf(), scanf() 和 malloc()就是这样工作的：调用者通过if等语句来测试返回值判断函数是否成功。

　　尽管返回代码技术有时是最适当的错误处理技术，但会增加不必要的if语句这样的令人讨厌的效果。

　　质量降级：众所周知，条件语句可能包含的错误大约十倍于其他类型的语句。因此，在其他都相同时，如果你能从代码中消除条件语句，你会得到更健壮的代码。
　　推迟面市：由于条件语句是分支点，而它们关系到白盒法测试时的测试条件的个数，因此不必要的条件语句会增加测试的时间总量。如果你没有走过每个分支点，那么你的代码中就会有在测试中没有被执行过的指令，直到用户／客户发现它，那就糟糕了。
　　增加开发成本：不必要的控制流程的复杂性增加了寻找bug，修复bug，和测试的工作。
因此，相对于通过返回代码和if来报告错误，使用try / catch / throw所产生更少有bug，更低的开发成本和更快面市的代码。

如何处理构造函数的失败?

　　构造函数没有返回类型，所以返回错误代码是不可能的。因此抛出异常是标记构造函数失败的最好方法。

　　如果你没有或者不愿意使用异常，这里有一种方法。如果构造函数失败了，构造函数可以把对象带入一种“僵尸”状态。你可以通过设置一个内部状态位使对象就象死了一样，即使从技术上来说，它仍然活着。然后加入一个查询（“检察员”）成员函数，以便类的用户能够通过检查这个“僵尸位”来确定对象是真的活着还是已经成为僵尸（也就是一个“活着的死对象”）。你也许想有另一个成员函数来检查这个僵尸位，并且当对象并不是真正活着的时候，执行一个 no-op（或者是更令人讨厌的如 abort()）。这样做真的不漂亮，但是如果你不能（或者不想）使用异常的话，这是最好的方法了。

　　如何处理析构函数的失败？

　　往log文件中写一个消息。但不要抛出异常！

　　C++的规则是你绝对不可以在另一个异常的被称为“栈展开(stack unwinding)”的过程中时，从析构函数抛出异常。举例来说，如果某人写了throw Foo()，栈会被展开，以至throw Foo()和 } catch (Foo e) { 之间的所有的栈页面被弹出。这被称为栈展开(statck unwinding)

　　在栈展开时，栈页面中的所有的局部对象会被析构。如果那些析构函数之一抛出异常（假定它抛出一个Bar对象），C++运行时系统会处于无法决断的境遇：应该忽略Bar并且在} catch (Foo e) { 结束？应该忽略Foo并且寻找 } catch (Bar e) { ？没有好的答案——每个选择都会丢失信息。

　　因此C++语言担保，当处于这一点时，会调用terminate()来杀死进程。突然死亡。

　　防止这种情况的简单方法是不要从析构函数中抛出异常。但如果你真的要聪明一点，你可以说"当处理另一个异常的过程中时，不要从析构函数抛出异常"。但在第二种情况中，你处于困难的境地：析构函数本身既需要代码处理抛出异常，还需要处理一些“其他东西”，调用者没有当析构函数检测到错误时会发生什么的担保（可能抛出异常，也可能做一些“其他事情”）。因此完整的解决方案非常难写。因此索性就做一些“其他事情”。也就是，不要从析构函数中抛出异常。

　　当然，由于总有一些该规则无效的境况，这些话不应该被“引证”。但至少99%的情况下，这是一个好规则。

　　如果构造函数会抛出异常，我该怎样处理资源？

　　对象中的每个数据成员应该清理自己。

　　如果构造函数抛出异常，对象的析构函数将不会运行。如果你的对象需要撤销一些已经做了的动作（如分配了内存，打开了一个文件，或者锁定了某个信号量），这些需要被撤销的动作必须被对象内部的一个数据成员记住。