Effective C++学记之08 别让异常逃离析构函数

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

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

例：数据库连接类
class DBConnection{
public:
    ...
    static DBConnection create();
    void close();  //关闭联机，失败则抛出异常
}；
为了确保客户不忘调用close()，一个合理的想法是创建一个用来管理DBConnection资源的类，并在其析构函数中调用close。
class DBConn{
public:
    ...
    ~DBConn()
    {
        db.close();
    }
private:
    DBConnection db；
}；
这边允许客户写出这样的代码：
{
    DBConn dbc(DBConnection::create())
    ...                   //在区块结束点，DBConn被销毁，自动调用db.close()
}
只要调close成功，一切美好。但如果导致异常，DBConn析构函数会传播该异常，也就是允许它离开这个析构函数。
那会抛出难以驾驭的麻烦,导致不明确的行为。

两个办法可以避免这一问题：

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

DBConn::~DBConn()
{
    try{db.close();}
    catch(...){
        制作运转记录，几下对close的调用失败；
        std::abort();
    }
}
（2）吞下异常：
DBConn::~DBConn()
{
    try{db.close();}
    catch(...){
        制作运转记录，几下对close的调用失败；
    }
}
一般情况下吞下异常压制了“某些动作失败”的重要信息，并不是一个好主意。但是可以让程序继续可靠的执行，即使在遭遇并忽略一个错误之后。

但是以上的2种方法都无法对抛出异常做出反应。较佳的策略是重新设计接口，使客户有机会对可能出现的问题做出反应。
class DBConn{
public:
    ...
    void close()
    {
        db.close();
        closed = true;
    }
    ~DBConn()
    {
        if(!closed){
            try{db.close();}
            catch(...){
                ...记录下来或结束程序或吞下异常。
            }
        }
    }
private:
    DBConnection db；
    bool closed；
}；
以上代码可见把调用close的责任从DBConn析构函数手上转移到客户手上（但DBConn析构函数仍内含一个双保险调用）。
如果客户不自己调用处理close，在析构函数抛出异常时客户就没有立场抱怨，毕竟他们有机会第一手处理问题，而他们选择了放弃。