Effective C++_笔记_条款08_别让异常逃离析构函数

（整理自Effctive C++，转载请注明。整理者：华科小涛@http://www.cnblogs.com/hust-ghtao/）

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

class Widget{
public:
    ...
    ~Widget() {...}    //假设这个可能吐出一个异常
};

void doSomething()
{
    vector<Widget> v ;  //v在这里被自动销毁
    ...
}

    当vector v被销毁，它有责任销毁其内含的所有Widgets。销毁第一个抛出异常，销毁第二个抛出异常…，异常对C++而言太多了。其实，在两个异常同时存在的情况下，程序不是结束执行就是导致不明确的行为。

    C++不喜欢析构函数抛出异常，但如果你的析构函数必须执行一个动作，而该动作可能在失败时抛出异常，该怎么办？例如你有class负责数据库连接：

class DBConnection{
public:
    ...
    static DBconnection create() ; //这个函数返回DBConnection对象

    void close () ;  //关闭联机；失败就抛出异常
};

         

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

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

    这样如果用户在某一区块，实例化DBConn对象时，在该区块结束时，会自动调用该对象的析构函数，确保该资源管理对象管理的DBConnection对象close。只要调用close成功，一切美好。但如果该调用导致异常，DBConn析构函数会传播该异常。三个办法可以解决这一问题：

1 如果close抛出异常就结束程序

    通常通过调用abort完成：

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

    如果程序遭遇一个“于析构期间发生错误”后无法继续执行，就强迫结束程序。这种方法可以阻止异常从析构函数传播出去，调用abort可以抢先制“不明确行为”于死地。

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

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

    }
}

    一般而言，将异常吞掉是个坏主意，因为它压制了“某些动作失败”的重要信息！然而有时候吞下异常也比负担“草率结束程序”或“不明确行为带来的风险好”。

3 设计接口使用户有机会处理

    一个更好的策略是重新设计DBConn接口，使其客户有机会对可能出现的问题做出反应。例如DBConn自己可以提供一个close函数，因而赋予客户一个机会得以处理“因该操作而发生的异常”。DBConn也可以追踪其所管理的对象是否已被关闭，并在答案为否的情况下有析构函数关闭。

class DBConn{
public:
    ...
    void close () // 供客户使用的新函数
    {
        db.close() ;
       closed = true ;
    }
    ~DBConn()
    {
        if(!closed){
            try{
                db.close();   //关闭连接（如果客户不那么做）
            }
            catch(...){
                   制作运转记录,记下对close调用失败;    // 如果关闭动作失败，记录下来并结束程序或吞下异常
             }
        }

    }
ptivate:
    DBConnection db ;
    bool closed ;
};

    把调用close的责任从DBConn析构函数转移到客户手上是给他们一个处理错误的机会，否则它们没机会响应。如果他们不认为这个机会有用，可以忽略，以来DBConn的析构函数调用close。如果真有错误发生——如果close的确抛出异常——而且DBConn析构函数结束程序或吞下该异常，客户没有立场抱怨。

    请记住：

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

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