# [17] 异常和错误处理 ## FAQs in section [17]: * [17.1] `try` / `catch` / `throw` 通过哪些方法来改善软件质量？ * [17.2] 如何处理构造函数的失败? * [17.3] 如何处理析构函数的失败？ * [17.4] 如果构造函数会抛出异常，我该怎样处理资源？ * [17.5] 当别人抛出异常时，我如何改变字符数组的字符串长度来防止内存泄漏？ ## 17.1 `try` / `catch` / `throw` 通过哪些方法来改善软件质量？ 通过排除使用`if`语句的一个理由。 代替 `try` / `catch` / `throw` 的通常做法是返回一个返回代码（有时称为错误代码），调用者通过诸如`if`的条件语句明确地测试。例如，`printf()`, `scanf()` 和 `malloc()`就是这样工作的：调用者被假定为会测试返回值来判断函数是否成功。 尽管返回代码技术有时是最适当的错误处理技术，但会产生增加不必要的`if`语句这样的令人讨厌的效果。 * **质量降级：**众所周知，条件语句可能包含的错误大约十倍于其他类型的语句。因此，在其他都相同时，如果你能从代码中消除条件语句，你会得到更健壮的代码。 * **推迟面市：**由于条件语句是分支点，而它们关系到白盒法测试时的测试条件的个数，因此不必要的条件语句会增加测试的时间总量。如果你没有走过每个分支点，那么你的代码中就会有在测试中没有被执行过的指令，直到用户／客户发现它，那就糟了。 * **增加开发成本：**不必要的控制流程的复杂性增加了寻找bug，修复bug，和测试的工作。 因此，相对于通过返回代码和`if`来报告错误，使用`try` / `catch` / `throw`所产生更少有bug，更低的开发成本和更快面市的代码。当然，如果你的团队没有任何使用`try` / `catch` / `throw`的经验，你也许想先在一个玩具性的项目上使用一下，以便确定你明白正在做的事情——在把武器拿上真枪实弹的前线前，总应该演练一下吧。 ## 17.2 如何处理构造函数的失败? 抛出一个异常。 构造函数没有返回类型，所以返回错误代码是不可能的。因此抛出异常是标记构造函数失败的最好方法。 如果你没有或者不愿意使用异常，这里有一种方法。如果构造函数失败了，构造函数可以把对象带入一种“僵尸”状态。你可以通过设置一个内部状态位使对象就象死了一样，即使从技术上来说，它仍然活着。然后加入一个查询（“检察员”）成员函数，以便类的用户能够通过检查这个“僵尸位”来确定对象是真的活着还是已经成为僵尸（也就是一个“活着的死对象”）。你也许想有另一个成员函数来检查这个僵尸位，并且当对象并不是真正活着的时候，执行一个 no-op（或者是更令人讨厌的如 `abort()`）。这样做真的不漂亮，但是如果你不能（或者不想）使用异常的话，这是最好的方法了。 ## 17.3 如何处理析构函数的失败？ 往log文件中写一个消息。或打电话给Tilda舅妈。但不要抛出异常！ 以下是为什么（扣好你的安全带）： 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%的情况下，这是一个好规则。 ## 17.4 如果构造函数会抛出异常，我该怎样处理资源？ 对象中的每个数据成员应该清理自己。 如果构造函数抛出异常，对象的析构函数将不会运行。如果你的对象需要撤销一些已经做了的动作（如分配了内存，打开了一个文件，或者锁定了某个信号量），这些需要被撤销的动作必须被对象内部的一个数据成员记住。 例如，应该将分配的内存赋给对象的一个“智能指针”成员对象`Fred`，而不是分配内存给未被初始化的`Fred*` 数据成员。这样当该智能指针消亡时，智能指针的析构函数将会删除`Fred`对象。标准类`auto_ptr`就是这种“智能指针”类的一个例子。你也可以写你自己的引用计数智能指针。你也可以用智能指针来指向磁盘记录或者其它机器上的对象。 ## 17.5 当别人抛出异常时，我如何改变字符数组的字符串长度来防止内存泄漏？ 如果你要做的确实需要字符串，那么不要使用`char`数组，因为数组会带来麻烦。应该用一些类似字符串类的对象来代替。 例如，假设你要得到一个字符串的拷贝，随意修改这个拷贝，然后在修改过的拷贝的字符串末尾添加其它的字符串。字符数组方法将是这样： ```  void userCode(const char* s1, const char* s2)  {    // 制作s1的拷贝：    char* copy = new char[strlen(s1) + 1];    strcpy(copy, s1);    // 现在我们有了一个指向分配了的自由存储的内存的指针， // w我们需要用一个try块来防止内存泄漏：    try {      // ... n现在我们随意乱动这份拷贝... // 将s2 添加到被修改过的 copy 末尾： // ... [在此处重分配 copy] ...      char* copy2 = new char[strlen(copy) + strlen(s2) + 1];      strcpy(copy2, copy);      strcpy(copy2 + strlen(copy), s2);      delete[] copy;      copy = copy2;      // ... 最后我们再次随意乱动拷贝...    } catch (...) {      delete[] copy;   // 得到一个异常时，防止内存泄漏      throw;           // 重新抛出当前的异常    }    delete[] copy;     // 没有得到异常时，防止内存泄漏  } ``` 象这样使用`char*`s是单调的并且容易发生错误。为什么不使用一个字符串类的对象呢？你的编译器也许提供了一个字符串类，而且它可能比你自己写的`char*`s更快，当然也更简单、更安全。例如，如果你使用了标准化委员会的字符串类`std::string`，你的代码看上去就会象这样： ```  #include <string>           // 让编译器找到 std::string 类  void userCode(const std::string& s1, const std::string& s2)  {    std::string copy = s1;    // 制作s1的拷贝 // ... 现在我们随意乱动这份拷贝...    copy += s2;               // A将 s2 添加到被修改过的拷贝末尾 // ... 最后我们再次随意乱动拷贝...  } ``` 函数体中总共只有两行代码，而前一个例子中有12行代码。节省来自内存管理，但也有一些是来自于我们不必先式的调用`str_xxx_()`例程。这里有一些重点： * 由于`std::string`自动处理了内存管理，当增长字符串时，我们不需要先式地写任何分配内存的代码。 * 由于`std::string`自动处理了内存管理，在结束时不需要 `delete[]` 任何东西。 * 由于`std::string`自动处理了内存管理，在第二个例子中不需要 `try` 块，即使某人会在某处抛出异常。