Effective C++——条款8(第2章)

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

Prevent exception from leving destructors.

C++并不禁止析构函数吐出异常,但它不鼓励这样做.这是有原因的,考虑以下代码:

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

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

这很容易理解,但如果析构函数必须执行一个动作,而该动作可能会在失败时抛出异常,该怎么办?例如,假设使用一个 class 负责数据库连接:

class DBConnection {
public:
    static DBConnection create();    // 这个函数返回DBConnection对象
    void close();                    // 关闭联机;失败则抛出异常
};

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

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

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

{                                        // 开启一个区块block
    DBConn dbc(DBConnection::create());  // 建立DBConnection对象并交给DBConn对象管理
    ...
}                                        // 在区块结束点,DBConn对象被销毁,自动调用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;
    }
    ~DBCoon() {
        if (!closed) {
            try {                                     // 关闭连接    
                db.close();
            } catch ( ... ) {                         // 如果关闭动作失败
                ***运转记录,记下对close的调用失败    // 结束程序或吞下异常
                ...
            }
        }
    }
private:
    DBConnection db;
    bool closed;
};

把调用close的责任从DBConn析构函数上移到DBConn客户上,是可以的.如果某个操作可能在失败时抛出异常,而又存在某种需要必须处理该异常,那么这个异常必须来自析构函数以外的某个函数.因为析构函数吐出异常就是危险,总会带来"过早结束程序"或"发生不明确行为"的风险.本例要说的是,由客户自己调用close并不会对他们带来负担,而是给他们一个处理错误的机会,否则他们没机会响应.如果他们不认为这个机会有用,可以忽略它,依赖DBConn析构函数去调用close.

注意:

析构函数绝对不要吐出异常.如果一个被析构函数调用的函数可能抛出异常,析构函数应该捕捉任何异常,然后吞下它们(不传播)或结束程序.

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