条款08：别让异常逃离析构函数

C++并不禁止析构函数吐出异常但它不鼓励你这样做。这是有理由的。考虑一下代码：

class Widget 
{ 
public: 
  ... 
  ~Widget(){...}//假设这个可能吐出一个异常 
}; 
void doSomething() 
{ 
  std::vector<Widget> v; 
  ... 
} 
//v在这里被自动销毁 

当vector v被销毁，它有责任销毁其内涵的所有Widgets。假设v内含十个Widgets,而在析构第一个元素期间，有个异常被抛出。其他九个Widgets还是应该被销毁（否则它们保存的任何资源都会发生泄漏），因此v应该调用它们各个析构函数。但假设在那些调用期间，第二个Widget析构函数又抛出异常。现在有两个同时作用的异常，这对C++而言太多了。在两个异常同时存在的情况下，程序若不是结束执行就是导致不明确行为。本例中会导致不明确行为。使用标准程序库的任何其他容器或TR1的任何容器或甚至array，也会出现相同情况。容器或array并非遇上麻烦的必要条件，只是析构函数吐出异常，即使并非使用容器或array，程序也可能过早结束或出现不明确行为。是的，C++不喜欢析构函数吐出异常！

如果你的析构函数必须执行一个动作而该动作可能会在失败时抛出异常，该怎么办？举个例子，假设你使用一个类来负责数据库连接：

class DBConnection 
{ 
public: 
   ... 
   static DBConnection create();//这个函数返回DBConnection对象； 
                                //为求简化暂略参数 
   void close();//关闭连接；失败则抛出异常 
}; 

为了确保客户不忘记DBConnection对象身上调用close()，一个合理的想法是创建一个用来管理DBConnection资源的类，并在其析构函数中调用close。这一类用于资源管理的类在第三章详细讨论，这里只是考虑它们的析构函数长相：

class DBConn  //这个类用来管理DBConnection 
{ 
public: 
   ... 
   ~DBConn()//确保数据库连接总是会被关闭 
   { 
     db.close(); 
   } 
private: 
  DBConnection db; 
}; 

这便允许客户写出这样的代码：

{                                  //开启一个区块 
DBConn dbc(DBConnection::create());//建立DBConnection对象并 
                                   //交给DBConn对象以便管理。 
...                                //通过DBConn的接口 
                                   //使用DBConnection对象。 
｝                                 //在区块结束点，DBConn对象 
                                   //被销毁，因而自动 
                                   //为DBConnection对象调用close 

只要调用close成功一切都美好，但如果该调用导致异常，DBConn析构函数会传播该异常，也就是允许它离开这个析构函数，那会造成问题，因为那就是抛出了难以驾驭的麻烦。

两个办法可以避免这个问题。DBConn的析构函数可以：

1.如果close抛出异常就结束程序，通常通过调用abort完成：

DBConn::~DBConn() 
{ 
   try 
   { 
      db.close(); 
   }catch(...) 
   { 
     //制作运转记录，记下对close的调用失败; 
     std:abort(); 
   } 
} 

“强迫结束程序”是个合理选项。毕竟它可以阻止异常从析构函数传播出去。也就是说调用abort可以抢先制“不明确行为”于死地

2.吞下调用close而发生的异常：

DBConn::~DBConn() 
{ 
  try 
  { 
    db.close(); 
  }catch(...) 
  { 
    //制作运作记录，记下对close的调用失败； 
  } 
} 

一般而已将异常吞掉是个坏主意，因为它压制了“某些动作失败”的重要信息！然而有时候吞下异常也比负担“草率结束程序”或者“不明确行为带来的风险”好，为了让这个成为一个可行方案，程序必须能够继续可靠的执行，即使在遭遇并忽略一个错误之后。

这些办法都没有什么吸引力。问题在于两者都无法对“导致close抛出异常”的情况做出反应。

 

一个较佳的策略是设计一个DBConn接口，使其客户有机会会可能出现的问题做出反应。例如DBConn自己可以提供一个close函数，因而赋予客户一个机会得以处理“应该操作而发生的异常”。DBConn也可以追踪其所管理之DBConnection是否已被关闭，并在答案为否的情况下由其析构函数关闭之。这可防止遗失数据库连接。然而如果DBConnection析构函数调用close失败，我们有将退回“强迫结束程序”或“吞下异常”的老路：

class DBConn 
{ 
public: 
  ... 
  void close()//供客户使用的新函数 
  { 
    db.close(); 
    closed = true; 
  } 
  ~DBConn() 
  { 
    if(!closed) 
    { 
      try //关闭连接（如果客户不那么做的话） 
      { 
        db.close(); 
      }catch(...) 
      { 
        //制作运作记录，记下对close的调用失败； 
        ... 
      } 
    } 
  } 
 
private: 
  DBConnection db; 
  bool closed; 
}; 

把调用close的责任从DBConn析构函数手上移到DBConn客户手上（但DBConn析构函数仍内含一个“双保险”调用）可能会给你“肆无忌惮转移负担”的印象。如果某个操作可能在失败时抛出异常，而又存在某种需呀必须处理该异常，那么这个异常必须来自析构函数以外的某个函数。因为析构函数吐出异常就是危险，总会带来“过早结束程序”或“发生不明确行为”的风险。本例要说明的是，由客户自己调用close并不会对它们带来负担，而是给它们一个处理错误的机会，否则他们没有机会响应。如果它们不认为这个机会有用，可以忽略它，以来DBConn析构函数去调用close。如果真有错误发生----如果close抛出异常---而且DBConn吞下该异常或结束程序，客户没有立场抱怨，毕竟他们曾有机会第一手处理问题，而他们放弃了。

 

1.析构函数绝对不要吐出异常。如果一个被析构函数调用的函数可能抛出异常，析构函数应该捕捉任何异常，然而吞下它们（不传播）或这结束程序。

2.如果客户需要对某个操作函数运行期间抛出的异常做出反应，那么类应该提供一个普通函数（而非在析构函数中）执行该操作。