Effective C++ 条款08：别让异常逃离析构函数

凡人叶枫2026-06-13 14:36

Effective C++ 条款08：别让异常逃离析构函数

在 C++ 中，异常机制是处理错误的重要手段。但有一个地方绝对不应该让异常逃逸出来------那就是析构函数。今天我们来深入探讨这个看似严格实则必要的规则。

一、问题的引入

假设我们有一个数据库连接类，在析构时需要关闭连接：

cpp 复制代码 
class DBConnection {
public:
    static DBConnection create() { return DBConnection(); }
    void close() {
        // 如果关闭失败，抛出异常
        if (!db_close(handle_)) {
            throw std::runtime_error("Close failed!");
        }
        closed_ = true;
    }
    ~DBConnection() {
        if (!closed_) {
            close();  // 危险！可能抛出异常
        }
    }
private:
    DBConnection() : handle_(db_open()), closed_(false) {}
    db_handle handle_;
    bool closed_;
};

这个设计有什么问题？

二、为什么异常不能逃离析构函数？

2.1 C++ 的异常处理机制

在 C++ 中，当异常被抛出时，栈会开始栈展开（stack unwinding）。栈展开的过程中，所有局部对象的析构函数都会被调用，以确保资源被正确释放。

cpp 复制代码 
void someFunction() {
    DBConnection conn = DBConnection::create();
    // ... 其他代码 ...
    throw std::exception("Something went wrong!");
    // conn 的析构函数会在这里被调用（栈展开过程中）
}

2.2 双重异常的灾难

现在，假设在栈展开过程中，另一个异常被抛出（比如 conn 的析构函数抛出了异常）：

cpp 复制代码 
void someFunction() {
    DBConnection conn1 = DBConnection::create();
    DBConnection conn2 = DBConnection::create();
    // ...
    throw std::exception("First exception");
    // 栈展开开始：
    // 1. 调用 conn2.~DBConnection() -> 抛出异常！
    // 2. 调用 conn1.~DBConnection() -> 又抛出异常！
}

C++ 标准明确规定：如果在栈展开过程中，析构函数抛出了异常且未被捕获，程序会立即调用 std::terminate()，导致程序非正常终止。

复制代码 
结果：程序直接崩溃！

2.3 即使不在栈展开中，也有问题

即使在正常的执行流程中，析构函数抛出异常也可能导致问题：

cpp 复制代码 
void process() {
    DBConnection conn = DBConnection::create();
    // ... 正常执行完毕，conn 离开作用域 ...
    // conn.~DBConnection() 抛出异常
}

int main() {
    try {
        process();
    } catch (const std::exception& e) {
        // 希望能捕获并处理异常
    }
    // 但如果 process() 中还有其他局部对象需要析构呢？
    // 异常会中断正常的析构流程
}

三、解决方案

3.1 方案一：吞下异常（Swallow the exception）

在析构函数中捕获所有异常，并记录日志：

cpp 复制代码 
class DBConnection {
public:
    ~DBConnection() {
        if (!closed_) {
            try {
                close();
            } catch (const std::exception& e) {
                // 记录日志，但不传播异常
                std::cerr << "Error in destructor: " << e.what() << std::endl;
                // 或者使用更专业的日志系统
                Logger::logError("DBConnection::~DBConnection() failed: %s", e.what());
            } catch (...) {
                // 捕获所有异常，确保什么都不抛出
                std::cerr << "Unknown error in destructor" << std::endl;
            }
        }
    }
};

优点：程序不会崩溃，栈展开可以正常完成。

缺点：错误被静默吞掉了，可能掩盖了真正的问题。

3.2 方案二：结束程序（Terminate the program）

如果错误非常严重，无法安全地继续运行：

cpp 复制代码 
class DBConnection {
public:
    ~DBConnection() {
        if (!closed_) {
            try {
                close();
            } catch (...) {
                // 记录错误
                Logger::logFatal("Critical error in DBConnection destructor!");
                // 结束程序
                std::abort();  // 或者 std::terminate()
            }
        }
    }
};

适用场景：数据一致性已经遭到破坏，继续运行可能导致更严重的损失。

3.3 方案三：将责任转移给调用者（最佳实践）

与其在析构函数中做可能失败的操作，不如提供一个显式的关闭接口，让用户有机会处理错误：

cpp 复制代码 
class DBConnection {
public:
    static DBConnection create() { return DBConnection(); }

    // 显式关闭，可能抛出异常
    void close() {
        if (closed_) return;
        if (!db_close(handle_)) {
            throw std::runtime_error("Failed to close database connection");
        }
        closed_ = true;
    }

    // 析构函数做兜底，但不抛异常
    ~DBConnection() {
        if (!closed_) {
            try {
                db_close(handle_);  // 直接调用，不经过可能抛异常的 close()
            } catch (...) {
                // 吞下异常，记录日志
                Logger::logError("DBConnection::~DBConnection(): close failed");
            }
        }
    }

private:
    DBConnection() : handle_(db_open()), closed_(false) {}
    db_handle handle_;
    bool closed_;
};

使用方式：

cpp 复制代码 
void processData() {
    DBConnection conn = DBConnection::create();
    // ... 使用 conn ...

    // 显式关闭，处理可能的错误
    try {
        conn.close();
    } catch (const std::exception& e) {
        // 优雅地处理关闭失败
        std::cerr << "Warning: connection close failed: " << e.what() << std::endl;
    }
}  // 如果 conn.close() 成功，析构函数什么都不做
  // 如果忘记调用 close()，析构函数会兜底，但吞下异常

四、实际应用场景

4.1 RAII 资源管理类

cpp 复制代码 
template<typename T>
class SmartPointer {
public:
    explicit SmartPointer(T* ptr) : ptr_(ptr) {}

    ~SmartPointer() {
        // delete 不会抛出异常，所以这里安全
        delete ptr_;
    }

    // 显式释放，允许调用者处理异常
    void reset(T* ptr = nullptr) {
        T* old = ptr_;
        ptr_ = ptr;
        if (old) {
            // 如果 T 的析构函数可能抛异常，这里需要注意
            // 但通常 delete 本身不抛异常
            delete old;
        }
    }

private:
    T* ptr_;
};

4.2 事务管理类

cpp 复制代码 
class Transaction {
public:
    Transaction() : committed_(false) {
        begin_transaction();
    }

    // 显式提交，可能失败
    void commit() {
        if (committed_) return;
        if (!do_commit()) {
            throw TransactionException("Commit failed");
        }
        committed_ = true;
    }

    // 显式回滚
    void rollback() {
        if (committed_) return;
        do_rollback();
        committed_ = true;  // 标记为已处理
    }

    ~Transaction() {
        if (!committed_) {
            // 如果用户没有显式提交或回滚，自动回滚
            try {
                do_rollback();
            } catch (...) {
                // 记录日志，不抛异常
                Logger::logError("Transaction rollback failed in destructor");
            }
        }
    }

private:
    bool committed_;
};

使用方式：

cpp 复制代码 
void transferMoney(Account& from, Account& to, double amount) {
    Transaction tx;

    from.debit(amount);
    to.credit(amount);

    // 显式提交，如果失败可以处理
    try {
        tx.commit();
    } catch (const TransactionException& e) {
        tx.rollback();  // 手动回滚
        throw;  // 重新抛出，让上层处理
    }
}  // 如果中途异常，析构函数会自动回滚

4.3 文件句柄管理

cpp 复制代码 
class FileWriter {
public:
    explicit FileWriter(const std::string& path)
        : file_(std::fopen(path.c_str(), "w")) {}

    void write(const std::string& data) {
        if (std::fwrite(data.c_str(), 1, data.size(), file_) != data.size()) {
            throw IOError("Write failed");
        }
    }

    // 显式刷新，可能失败
    void flush() {
        if (std::fflush(file_) != 0) {
            throw IOError("Flush failed");
        }
        flushed_ = true;
    }

    ~FileWriter() {
        if (file_) {
            try {
                if (!flushed_) {
                    std::fflush(file_);  // 最后一次尝试刷新
                }
                std::fclose(file_);
            } catch (...) {
                // 绝对不能让异常逃离析构函数
                Logger::logError("FileWriter::~FileWriter() failed");
            }
        }
    }

private:
    FILE* file_;
    bool flushed_ = false;
};

五、C++11 及以后的补充

5.1 noexcept 关键字

C++11 引入了 noexcept 关键字，可以显式标记函数不会抛出异常：

cpp 复制代码 
class MyClass {
public:
    ~MyClass() noexcept {  // 显式承诺不抛异常
        // ...
    }
};

如果 noexcept 函数实际上抛出了异常，程序会立即调用 std::terminate()。

从 C++11 开始，析构函数默认就是 noexcept 的，这意味着编译器会帮你强制执行"不抛异常"的约定。

5.2 移动操作与异常

在实现移动构造函数和移动赋值运算符时，也需要考虑异常安全：

cpp 复制代码 
class MyClass {
public:
    MyClass(MyClass&& other) noexcept {  // 标记为 noexcept
        // 移动操作通常不抛异常
        data_ = other.data_;
        other.data_ = nullptr;
    }

    ~MyClass() noexcept {
        delete data_;
    }
};

如果移动构造函数标记为 noexcept，STL 容器在重新分配内存时会优先使用它，而不是拷贝构造函数。

六、常见误区

6.1 "我的析构函数很简单，不会抛异常"

即使你的析构函数看起来很简单，它调用的其他函数也可能抛异常：

cpp 复制代码 
class Widget {
public:
    ~Widget() {
        cleanup();  // 你确定 cleanup() 不会抛异常吗？
    }
private:
    void cleanup() {
        resource_.release();  // 这个呢？
    }
    SomeResource resource_;
};

最佳实践：在析构函数中，对所有可能失败的操作都使用 try-catch 保护。

6.2 "我用智能指针了，不需要关心"

智能指针的析构函数本身不会抛异常，但它管理的对象如果在析构时抛异常，问题依然存在：

cpp 复制代码 
class BadClass {
public:
    ~BadClass() {
        throw std::exception("Oops!");  // 千万别这样！
    }
};

std::unique_ptr<BadClass> p(new BadClass());
// p 销毁时，BadClass 的析构函数抛异常 -> 程序终止

七、总结

方案 适用场景 优缺点
吞下异常 大多数情况 程序稳定运行，但可能掩盖问题
结束程序 致命错误，无法安全继续 避免数据损坏，但用户体验差
显式接口 + 析构兜底 最佳实践 给用户处理错误的机会，析构做安全兜底

请记住：

  • 析构函数绝对不要吐出异常。
  • 如果一个析构函数可能抛出异常，析构函数应该捕捉任何异常，然后吞下它们（记录日志）或结束程序。
  • 更好的设计是提供一个显式的关闭/清理接口，让调用者有机会处理错误，而析构函数只做安全的兜底操作。
  • 从 C++11 开始，析构函数默认是 noexcept 的。

异常是 C++ 中强大的错误处理工具，但在析构函数这个特殊场景中，"不抛异常"不是限制，而是保护。遵循这个规则，你的代码将更加健壮和可靠。

参考阅读：

  • 《Effective C++》第三版，Scott Meyers
  • 《C++ Primer》第五版，关于异常安全的章节
  • C++ Core Guidelines: E.16
相关推荐
这个DBA有点耶5 小时前
NULL不是空——数据库里最反直觉的设计，90%新人踩过的坑
数据库·mysql·代码规范
karry_k5 小时前
MyBatis批量insert-select踩坑：useGeneratedKeys=true 可能让PostgreSQL返回大量插入结果
java·后端
karry_k5 小时前
PostgreSQL 在 MyBatis 中执行正常 SQL 失效：一次 DELETE USING 踩坑记录
java·后端
这个DBA有点耶7 小时前
AI写的SQL跑崩了生产库，这锅谁背？
数据库·人工智能·程序员
镜舟科技7 小时前
Databricks 再提 LTAP，AI 时代的数据底座为何重回大一统叙事？
数据库·架构·agent
Databend8 小时前
从湖仓升级为 Agent 时代的数据控制面，Snowflake 和 Databricks 有哪些布局
大数据·数据库·agent
SamDeepThinking9 小时前
从源码到代码：MyBatis-Flex 与 MyBatis-Plus 的逐项对比
java·后端·程序员
ClouGence11 小时前
SQL Server CDC 能放到 Always On 备库读吗？一文讲透原理与实践
数据库·sql server
她的男孩12 小时前
Spring Boot 接 Flowable 工作流：用 3 个注解搭一个请假审批流程
java·后端·架构
荣码13 小时前
LLM结构化输出：让AI返回JSON而不是废话，我踩了4个坑
java·python
热门推荐
012026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf02GitHub 镜像站点03【AI】2026 年具身智能模型和世界模型总结042026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？052026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？06Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析072026 年 AI 大模型 & AI 编程工具实战全总结082026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？09AI科技热点日报 | 2026年07月01日10Trae国际版与国内版深度测评：AI原生IDE的双生花