1.为什么c++不喜欢析构函数抛出异常
C++并没有禁止析构函数出现异常，但是它肯定不鼓励这么做。这是有原因的，考虑下面的代码：
1 class Widget { 2 3 public: 4 5 ... 6 7 ~Widget() { ... } // assume this might emit an exception 8 9 }; 10 11 void doSomething() 12 13 { 14 15 std::vector<Widget> v; 16 17 ... 18 19 } // v is automatically destroyed here
当vector V被销毁，V有责任将它包含的所有Widgets都销毁。假设v含有有10个Widgets对象，当销毁第一个Widgets对象时，抛出了一个异常。其余的9个仍然需要被释放掉（否则它们拥有的资源会被泄露），所以V应该触发其余9个对象所有的析构函数。但是假设在这9个析构函数调用过程中，第二个Widget的析构函数抛出了一个异常。现在有两个主动抛出的异常了，这对c++来说太多了。在两个异常同时出现的情况下，程序的执行要么终止要么产生未定义行为。在这个例子中，它会产生未定义行为。使用任何其他标准库容器(如list或set)或者TR1中的容器，甚至一个数组也将会产生同样的未定义行为。出现这种麻烦并不只是在容器或者数组中出现。在不使用容器或者数组的情况下，析构函数抛出的异常也可以使程序过早终止或者出现未定义行为。C++不喜欢析构函数发出异常！
2.一个例子-DB资源管理类
这很容易理解，但是析构函数需要执行的操作有可能由于异常被抛出而导致失败，这时候我们应该怎么做？举个例子，假设你在实现一个关于数据库连接的类：
1 class DBConnection { 2 3 public: 4 5 ... 6 7 static DBConnection create(); // function to return 8 9 // DBConnection objects; params 10 11 // omitted for simplicity 12 13 void close(); // close connection; throw an 14 15 }; // exception if closing fails
为了确保客户端不会忘记调用DBConnection对象的close函数，为DBConnestion创建一个资源管理类是一个理想的方法，close函数会在资源管理类的析构函数中被调用。这样的资源管理类将在第三章有详细的讲述，在这里，考虑这样一个类的析构函数会长成什么样子就足够了：
1 class DBConn { // class to manage DBConnection 2 3 public: // objects 4 5 ... 6 7 ~DBConn() // make sure database connections 8 9 { // are always closed 10 11 db.close(); 12 13 } 14 15 private: 16 17 DBConnection db; 18 19 };
于是客户端代码可以写成这样：
1 { // open a block 2 3 DBConn dbc(DBConnection::create()); // create DBConnection object 4 5 // and turn it over to a DBConn 6 7 // object to manage 8 9 ... // use the DBConnection object 10 11 // via the DBConn interface 12 13 } // at end of block, the DBConn 14 15 // object is destroyed, thus 16 17 // automatically calling close on 18 19 // the DBConnection object
只要close函数的调用成功了这个实现就是很好的，但是如果调用产生一个异常，DBConn的析构函数会传播这个异常，也就是允许异常离开析构函数。这是一个问题，因为在析构函数中发生throw就意味这麻烦。
3.如何阻止析构函数中的异常被传播出去
有两种方法来避免这个麻烦。DBConn的析构函数可以这么做：
3.1用abort函数使程序终止
如果close函数抛出异常就将程序终止，可以调用abort函数：
1 DBConn::~DBConn() 2 3 { 4 5 try { db.close(); } 6 7 catch (...) { 8 9 make log entry that the call to close failed; 10 11 std::abort(); 12 13 } 14 15 }
如果在执行析构函数的时候遇到一个错误程序就不能继续运行了，上面的做法会是一个合理的选择。它的优点是能够阻止异常从析构函数传播出去，传播异常会导致未定义行为。因此，对于未定义行为，调用abort能够先发制人。
3.2 将异常吞掉
将调用close时抛出的异常吞掉
1 DBConn::~DBConn() 2 3 { 4 5 try { db.close(); } 6 7 catch (...) { 8 9 make log entry that the call to close failed; 10 11 } 12 13 }
在一般情况下，将异常吞掉是一个坏的方法，因为它会抑制重要错误信息-有一些失败的事情-的出现！但是有时候，比起程序过早终止或者未定义行为，将异常吞掉会是更好的方法。这是一个可行的选择，程序必须能够可靠的继续执行下去甚至在碰到错误出现然后将其忽略的情况。
这两种方法都不是特别吸引人。这两种的方法的问题是，程序没有办法在第一时间对导致close抛出异常的条件做出反应。
4.一个更好的方法-使类能够对异常做出反应
一个更好的方法是对DBConn的接口进行设计，于是客户端有机会对可能出现的问题做出反应。举个例子，DBConn类自己可以提供一个close函数，这就可以给客户端一个处理从close抛出异常的机会，同时也能够追踪DBConnection是否已经被关掉了，如果在close中没有被关掉就在析构函数中再次执行。这就阻止了连接无法被正确释放。如果在DBConn的析构函数中对close的调用将会失败，我们还得使用终止程序或者吞掉异常的方法：
1 class DBConn { 2 3 public: 4 5 ... 6 7 void close() // new function for 8 9 { // client use 10 11 db.close(); 12 13 closed = true; 14 15 } 16 17 ~DBConn() 18 19 { 20 21 if (!closed) { 22 23 try { // close the connection 24 25 db.close(); // if the client didn’t 26 27 } 28 29 catch (...) { // if closing fails, 30 31 make log entry that call to close failed; // note that and 32 33 ... // terminate or swallow 34 35 } 36 37 } 38 39 } 40 41 private: 42 43 DBConnection db; 44 45 bool closed; 46 47 };
将调用close的责任从DBConn的析构函数转移到DBConn的客户端（因为DBConn的析构函数有一个“备份”调用）可能会给你肆无忌惮转移负担的印象。你可能甚至将这种做法当成Item18给出意见的反例（使接口容易被正确使用）。事实上，这两种想法都是错的。如果一个操作有可能因为抛出异常而导致失败，而我们有可能需要去处理这个异常，这个异常必须来自非析构函数才可以。因为析构函数抛出异常是很危险的，常常会导致程序过早终止或者未定义行为。在这个例子中，告诉客户端自己调用close函数并没有给它们增加负担；这反而给了它们一个处理错误的机会，否则就没有机会对错误做出反应了。如果他们发现这个机会没有什么用(可能因为他们相信没有错误会发生)，他们可以忽略它，仅依靠DBConn的析构函数在调用close。如果这时出现了错误-close确实抛出了异常-他们没有资格抱怨DBConn吞掉了异常或者终止了程序。毕竟，他们原来有机会处理这个问题，但是他们没有这么做。
5.总结
- 析构函数不能够发出任何异常。如果在析构函数中调用某个函数可能会发生throw,析构函数应该catch所有异常然后吞掉他们或者终止程序。
- 如果类的客户端需要对一个操作的异常throw做出反应，这个类应该提供一个普通函数来执行这个操作。