Item8：别让异常逃离析构函数

0.概述

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

1.如果一个被析构函数调用的函数可能抛出异常

例，一个负责数据库连接的class

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

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

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

class DBConn
{
    public:
        ...
        ~DBConn()
        {
            db.close();
        }
    private:
        DBConnection db;
};

这样就可以写出下述代码

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

如果该调用导致异常，DBConn 析构函数会传播该异常，也就是允许它离开这个析构函数。会带来”过早结束程序“或”发生不明确行为“的风险。

2.两种解决方案

写在前面：下述两种解决方案都没啥意思，因为都没有对”导致close抛出异常“的情况做出反应。

2.1 close抛出异常就结束程序（abort）

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

调用abort，抢先制不明确行为于死地。

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

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

这通常不是一个好的解决方案，因为它压制了”某些动作失败“的重要信息。

3.一种较佳的解决方案

重新设计DBConn接口，使客户有机会对可能出现的问题作出反应。

例如可以自己提供一个close函数，赋予用户一个机会得以处理”因该操作而发生的异常“

class DBConn {
    public:
        ...
        void close() // new function for
        { // client use
            db.close();
            closed = true;
        }
        ~DBConn()
        {
            if (!closed) {
            try { // close the connection
            db.close(); // if the client didn’t
            }
            catch (...) { // if closing fails,
            make log entry that call to close failed; // note that and
            ... // terminate or swallow
            }
            }
        }
    private:
        DBConnection db;
        bool closed;
};

如果某个操作可能在失败时抛出异常，而又存在某种需要必须处理该异常，那这个异常必须来自析构函数以外的某个函数。