别让异常逃离析构函数

C++并不禁止析构函数吐出异常，但它不鼓励这样做。如：

class Widget

{

  public:

   ...

  ~Widget(){...}   //这个可能会出现异常

};

 

void doSomething()

{

   vector<Widget> v

   ...

                     //v在这里被自动销毁

}

 

    当vector v被销毁，它有责任销毁其内含的所有Widgets，假设v内含十个Widgets，而在析构第一个元素期间，有个异常被抛出。其他九个Widgets还是应该被销毁（否则它们保存的任何资源都会发生泄漏），因此v应该调用它们各个析构函数。但假设在那些调用期间，第二个Widget析构函数又抛出异常。现在有两个同时作用的异常，这对C++而言太多了。在两个异常同时存在的情况下，程序若不是结束执行就是导致不明确的行为。所以，C++不喜欢析构函数出现异常。

 

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

class DBConnection

{

  public:

   ...

   static DBConnection create();

 

  void close();                           //关闭联机，失败则抛出异常

};

 

  为了确保客户不会忘记在DBConnection对象身上调用close()，一个合理的想法是创建一个用来管理DBConnection资源的class,并在析构函数中调用close:

class DBConn                 //这个类用来管理DBConnection对象

{

  public：

    ...

   ~DBConn()                //确保数据库连接总是会被关闭

    {

        db.close();

    }

   private:

     DBConnection db;

}；

现在就可以这样写代码：

 

{

   DBConn dbc(DBConnection::create());//建立一个DBConnection对象并交给DBConn管理

   //在区块结束时自动调用DBConn的析构函数,因而自动为DBConnection对象调用close

}

 

但是如果DBConn在调用析构函数时出现异常，DBConn析构函数会传播该异常，也就是允许它离开这个析构函数。那会造成问题，因为那就是抛出了难以驾驭的麻烦。

 

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

（1）如果close抛出异常就结束程序。通常通过调用abort完成

DBConn::~DBConn()

{

   try

    {db.close();}

    catch(...){

      //制作运转记录，记下对close的调用失败

      abort();

    }

}

 

这样做虽然很武断，但是毕竟它可以阻止异常从析构函数传播出去（那会导致不明确的行为）。也就是说调用abort可以抢先制“不明确行为”于死地。

（2）吞下因调用close而发生的异常：

DBConn::~DBConn()

{

   try

    {db.close();}

   catch(...){

       //制作运转记录,记下对close的调用失败  

  }

}

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

 

上面两种方法都不是很好。问题在于两者都无法对“导致close抛出异常”的情况作出反应。

 

一个较佳的策略是重新设计DBConn接口，使其客户有机会对可能出现的问题作出反应。如：

class DBConn

{

  public:

    ...

    void close()                                     //供客户使用的新函数

    {

       db.close();

       close = true;

    }

   ~DBConn()

    {

       if(!closed){

          try{                                       //关闭连接（如果客户不那么做的话）

              db.close();

         }catch(...){                                //如果关闭动作失败

             //制作运转记录，记下对close的调用失败   //记录下来并结束程序或吞下异常

         }

       }

    }

  priavte:

     DBConnection db;

     bool closed;

};

 

    现在，如果用户要自己处理可能出现的异常时，就自己调用DBConn的close函数，然后自己处理。如果用户不处理就使用默认的DBConn析构函数中的处理，这样就提供了用户自己处理可能出现的异常的机会。

 

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

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