Effective C++条款08——别让异常逃离析构函数（构造/析构/赋值运算）

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

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

};

void doSomething() {
    std::vector v;
    // ...
}                        // v在这里被销毁

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

原来如此

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

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

    
    void close();                        // 简化处理。这个函数失败时抛出异常
};

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

class DBCon {
public:
    // ...
    ~DBCon() {                // 确保数据库连接总被关闭
        db.close();
    }

private:
    DBConnection db;
};

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

{
    DBCon dbc(DBConnection::create());
    // ...

}
// 出上面这个区域后，DBCon对象会被销毁，会调用close

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

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

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

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

如果程序遭遇一个“于析构期间发生的错误”后无法继续执行，“强迫结束程序”是个合理选项。毕竟它可以阻止异常从析构函数传播出去（那会导致不明确的行为）。也就是说调用abort可以抢先制“不明确行为”于死地。

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

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

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

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

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

class DBCon {
public:
    // ...
    void close() {            // 供客户端使用新函数
        db.close();
        clsoed = true;
    }

    ~DBCon() {                // 确保数据库连接总被关闭
        db.close();
    }

    ~DBConn() {
        if (!closed) {        // 关闭连接
            try {
                db.close();
            }
            catch(...) {
                // 制作转运记录，记下对close的调用失败
            }
        }
    }
}

private:
    DBConnection db;
    bool closed;
};

之所以如此，是为了:
1.析构函数里不抛出异常,如果真有，就吞下;
2提供接口由客户显示清理，如有异常，交给客户处理;

把调用close的责任从 DBConn析构函数手上移到 DBConn客户手上(但 DBConn析构函数仍内含一个“双保险”调用）可能会给你“肆无忌惮转移负担”的印象。你甚至可能认为它违反条款18所提忠告（让接口容易被正确使用）。实际上这两项污名都不成立。如果某个操作可能在失败时抛出异常，而又存在某种需要必须处理该异常，那么这个异常必须来自析构函数以外的某个函数。因为析构函数吐出异常就是危险，总会带来“过早结束程序”或“发生不明确行为”的风险。本例要说的是，由客户自己调用close并不会对他们带来负担，而是给他们一个处理错误的机会，否则他们没机会响应。如果他们不认为这个机会有用（或许他们坚信不会有错误发生)，可以忽略它，倚赖DBConn析构函数去调用close。如果真有错误发生—---如果close的确抛出异常—--而且 DBConn吞下该异常或结束程序，客户没有立场抱怨，毕竟他们曾有机会第手处理问题，而他们选择了放弃。

请记住

• 析构函数绝对不要吐出异常。如果一个被析构函数调用的函数可能抛出异常，析构函数应该捕捉任何异常，然后吞下它们(不传播）或结束程序。
• 如果客户需要对某个操作函数运行期间抛出的异常做出反应，那么class应该提供一个普通函数（而非在析构函数中）执行该操作。