析构函数抛异常会导致std::terminate()强制终止程序，因栈展开时禁止双重异常；C++11起析构函数默认noexcept，违反即终止；安全做法是吞掉异常或拆分为显式关闭函数。
因为一旦析构函数抛出异常，程序大概率会立即调用 std::terminate() 终止运行——不是崩溃，而是无回旋余地的强制退出。
栈展开时抛异常直接触发 std::terminate()
当一个异常正在传播（比如 throw 之后、被 catch 之前），C++ 开始执行栈展开：自动调用所有已构造局部对象的析构函数。此时如果任一析构函数再抛出异常，就构成“双重异常”——C++ 标准明确禁止同时存在两个未处理的活跃异常。
结果不是跳到最近的 catch，而是直接终止进程。哪怕你写了 try 包围整个函数，也拦不住。
- 常见现象：
libc++abi.dylib: terminating with uncaught exception或std::terminate called after throwing an instance of ... - 即使析构函数在栈展开外单独执行（如
delete堆对象），C++ 仍将其视为“由系统调用”，异常无法被外围try捕获 - C++11 起，析构函数默认隐式为
noexcept(true)；若实际抛出异常，等同于违反契约，std::terminate()是标准行为，不是实现 bug
noexcept 不是可选项，是编译器级约束
你不能靠“我不写 noexcept”来绕过。C++11 及以后，所有用户声明的析构函数都自动带 noexcept，除非你显式写成 noexcept(false) ——但这是自找麻烦，编译器可能拒绝或静默修正。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
示例：
class DBConn {
public:
~DBConn() { // 等价于 ~DBConn() noexcept
db.close(); // 若 close() 抛异常，程序 terminate
}
private:
Database db;
};
- 显式加
noexcept是好习惯，但不加也不代表可以抛异常 - 某些编译器（如 GCC）对
noexcept违反会做优化假设，导致未定义行为比单纯 terminate 更难调试 - 模板类（如
std::vector<T>）在析构元素时，会依赖T::~T()是noexcept；若不是，可能导致容器操作（如resize）行为异常
资源泄漏比崩溃更隐蔽，且更常发生
很多人以为“只要 catch 住析构里的异常就安全了”，但问题远不止于此。析构函数里抛异常，哪怕没触发 std::terminate()，也会中断后续清理逻辑。
例如：
~ResourceHolder() {
file_.close(); // 可能抛异常
socket_.shutdown(); // 这行根本不会执行
log("released"); // 也不会执行
}
- 异常在
file_.close()抛出 →socket_.shutdown()和log()全部跳过 - 多个资源共存时（文件 + 数据库连接 + 内存映射），只释放第一个，其余全泄漏
- 这种泄漏不会报错，只会在长时间运行后暴露为句柄耗尽、内存增长、连接数超限等“慢病”
真正安全的替代方案只有两种
别试图在析构函数里“优雅处理错误”。要么吞掉，要么暴露给用户——但绝不能让异常逃逸。
- 用
try/catch(...)吞掉异常，并记录日志：std::cerr << "DB close failed in destructor" - 把可能失败的操作拆成普通成员函数（如
close()），让用户主动调用并处理异常；析构函数只做“尽力而为”的清理（比如关闭已知安全的句柄） - 优先用 RAII 封装资源本身（如
std::unique_ptr,std::lock_guard），它们的析构函数早已被设计为noexcept，无需你操心
最常被忽略的一点：析构函数的职责是释放资源，不是报告错误。错误该在哪发生，就在哪处理——放到构造、使用或显式关闭阶段，而不是塞进析构这个“收尾保险丝”里。
