Item 8：阻止异常逃离 destructor

从“第二个异常没有去处”开始

对象析构既发生在正常离开作用域，也发生在异常传播的

stack unwinding。

如果一个 primary exception 正在传播，某个 destructor 又抛出另一个异常，运行时无法同时传播两者，通常调用 std::terminate。

使外层 catch 无法选择保留哪一个。 Prevent exceptions from leaving destructors（阻止异常逃离析构函数）覆盖整个析构链：析构函数体、成员析构和基类析构产生的异常都必须在 no-throw boundary 内按策略处理。

一个元素析构可终止整个容器销毁

原书以数据库连接为例；数组或 vector 中多个对象析构时问题更明显：

class DBConnection {
public:
    void close(); // 可能抛异常
};
 
class DBConn {
public:
    ~DBConn()
    {
        db_.close(); // 异常可逃离 destructor
    }
private:
    DBConnection db_;
};

若 vector<DBConn> 销毁时第一个元素抛异常，剩余元素的清理和程序控制流都可能受破坏。

不是可在上层恢复的普通错误。

现代 destructor 默认倾向 noexcept

用户声明 destructor 通常隐式具有 noexcept 条件，取决于成员/基类析构。显式写 noexcept 可强调接口，但不能自动处理内部失败。

class DBConn {
public:
    ~DBConn() noexcept
    {
        try {
            db_.close();
        } catch (...) {
            record_cleanup_failure(std::current_exception());
        }
    }
private:
    DBConnection db_;
};

关键是 record_cleanup_failure 自身也不能抛；日志分配失败、锁失败都要考虑。

吞掉还是终止取决于不变量

适合失败不会破坏进程核心不变量，且调用方已没有恢复动作的 best-effort cleanup。

适合继续运行会产生数据损坏或安全风险。主动终止比异常偶然逸出更明确，但仍应让正常调用方有机会先处理。

~CriticalSession() noexcept
{
    try {
        rollback_if_active();
    } catch (...) {
        emergency_log();
        std::terminate();
    }
}

决定是否终止，而不是“析构永远吞掉”。

把可处理失败交给普通函数

class DBConn {
public:
    explicit DBConn(DBConnection connection)
        : db_{std::move(connection)} {}
 
    void close()
    {
        if (closed_)
            return;
        db_.close();      // 失败时调用方可 catch/retry
        closed_ = true;  // 只在成功后提交状态
    }
 
    ~DBConn() noexcept
    {
        if (!closed_)
            close_noexcept();
    }
private:
    void close_noexcept() noexcept;
    DBConnection db_;
    bool closed_{};
};

显式 close 让用户处理异常；destructor 是最后兜底，不能替代正常错误处理。

状态提交顺序决定重试语义

某些底层 API 失败后句柄状态未知，不能简单重试。wrapper 必须根据 API 契约定义 Active、Closed、Failed/Unknown 状态。

enum class CloseState { Active, Closed, Failed };
 
void Connection::close()
{
    if (state_ != CloseState::Active)
        return;
    try {
        native_close(handle_);
        state_ = CloseState::Closed;
    } catch (...) {
        state_ = CloseState::Failed;
        throw;
    }
}

destructor fallback 对此只能按协议记录或终止，不能盲目重复操作造成 double close。

commit 不应藏在 destructor

事务、文件 flush、网络发送等不应只在 destructor 执行，因为调用方无法可靠得知失败。

class Transaction {
public:
    void commit();
    ~Transaction() noexcept
    {
        if (!committed_)
            rollback_noexcept();
    }
private:
    bool committed_{};
};

RAII 负责“未提交则回滚”，调用方负责“提交是否成功”。这比 destructor 自动 commit 更符合异常安全。

scope guard 也必须 no-throw

auto rollback = ScopeExit{[&]() noexcept {
    restore_previous_state_noexcept();
}};
 
apply_changes();
rollback.release();

lambda 标记 noexcept 并不证明内部调用真的不抛，需要静态约束或内部 catch。通用 ScopeExit 可要求 std::is_nothrow_invocable_v<F&>。

第三方 destructor 会抛怎么办

不能修改第三方类时，在 wrapper 的显式 close 中调用并传播，在 destructor 中 catch all。若第三方 destructor 本身 noexcept(false)，把它作为成员会影响外层析构异常规范；可通过动态所有权和受控销毁隔离，但最终仍需处理。

void ThirdPartyOwner::destroy_noexcept() noexcept
{
    try {
        resource_.reset();
    } catch (...) {
        report_without_throwing(std::current_exception());
    }
}

在析构中保存到外部线程安全诊断通道仍需考虑分配与生命周期，不能保存回即将销毁对象。

选择失败策略

文件描述符 close、临时目录删除常属此类；事务 commit 不是。

是把 destructor 风险移回正常控制流的关键。

故障注入覆盖两种退出路径

先预测：正常作用域退出时 destructor 抛异常能否被外层 catch？若作用域内先抛 primary exception，结果又如何？分别运行，记录 terminate handler。

std::set_terminate([] {
    terminateObserved.store(true);
    std::_Exit(99);
});

terminate 测试应放独立进程，避免结束测试 runner。

• 正常显式 close 失败可被调用方 catch，状态符合协议。
• close 成功后 destructor 不重复调用底层 close。
• 忘记 close 时 destructor fallback 执行一次且不抛。
• primary exception unwinding 期间 cleanup 失败不产生 secondary exception。
• rollback 失败按策略记录或 terminate，测试进程退出码明确。
• 容器中一个元素 cleanup 失败不会阻止其余元素按策略清理。

小结

• stack unwinding 中 destructor 再抛 secondary exception 会触发 terminate
• destructor 应建立 no-throw cleanup boundary，不能让清理异常逃离
• 可恢复关闭失败通过 explicit close 暴露，destructor 只做幂等 fallback
• commit 属于可观察业务操作，应显式执行；destructor 更适合 no-throw rollback
• 吞掉、记录或 terminate 取决于继续运行是否破坏核心不变量
• 正常退出和异常 unwinding 必须分别做故障注入测试