侧边栏壁纸
博主头像
如此肤浅

但行好事,莫问前程!

  • 累计撰写 52 篇文章
  • 累计创建 6 个标签
  • 累计收到 6 条评论

目 录CONTENT

文章目录

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

如此肤浅
2022-05-14 / 0 评论 / 0 点赞 / 40 阅读 / 1,551 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-05-15,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

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

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

上述代码中,当 vector v 被销毁,它有责任销毁其内含的所有 Widgets。假设 v 内含十个 Widgets,而在析构第一个元素期间,有个异常被抛出。其他九个Widgets 还是应该被销毁(否则它们保存的任何资源都会发生泄漏),因此 v 应该调用它们各个析构函数。但假设在那些调用期间,第二个 Widget 析构函数又抛出异常。在两个异常同时存在的情况下,程序若不是结束执行就是导致不明确行为。

如果要在析构函数中执行一个动作,而该动作可能会在失败时抛出异常,该怎么办呢?

以数据库连接为例

设计一个类管理数据库连接、断开连接等相关操作:

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

如果析构函数中调用 close 失败,DBConn析构函数会传播该异常,也就是运行它离开这个析构函数。

为避免这一问题,DBConn 的析构函数可以采用下面两种处理方式:

  1. 如果 close 抛出异常就结束程序,通过调用 abort 实现

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

    如果程序遭遇一个“于析构期间发生的错误”后无法继续执行,“强迫结束程序”是个合理选项。因为它可以阻止异常从析构函数传播出去,不会导致发生不明确的行为。

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

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

    一般而言,将异常吞掉是个坏主意,因为它压制了“某些动作失败”的重要信息!然而有时候,为了使程序能够继续执行下去,吞下异常也比“草率结束程序”或发生“不明确行为”带来的风险小。

较佳的策略:
重新设计 DBConn 接口:

class DBConn {
public:
	...
    void close() // 提供给客户使用
    {
    	db.close();
        closed = true;
    }
    ~DBConn()
    {
    	if(!closed) {
        	try { // 关闭连接
            	db.close();
            }
            catch(...) { // 如果关闭失败,记录下来,并结束程序或吞下异常
            	制作运转记录,记下对close的调用失败;
                ...
            }
        }
    }
private:
	DBConnection db;
    bool closed;
}

把调用 close 的责任从 DBConn 析构函数手上移到 DBConn 客户手上(但 DBConn 析构函数仍内含一个“双重保险”的调用)可能会给你“肆无忌惮转移负担”的印象。如果某个操作可能在失败时抛出异常,而又存在某种需要必须处理该异常,那么这个异常必须来自析构函数以外的某个函数。 因为析构函数吐出异常就是危险,总会带来“过早结束程序”或“发生不明确行为”的风险。本例要说的是,由客户自己调用 close 并不会对他们带来负担,而是给他们一个处理错误的机会,否则他们没机会响应。如果他们不认为这个机会有用(或许他们坚信不会有错误发生),可以忽略它,倚赖 DBConn 析构函数去调用 close。

0

评论区