析构函数在栈展开期间抛异常会直接调用std::terminate。因C++标准强制要求此时终止程序，且无法被自定义handler捕获；根本原因是栈展开依赖析构函数安全完成，新异常使运行时无法抉择处理逻辑。
析构函数抛异常会直接触发 std::terminate
当析构函数中 throw 了异常，而此时程序已经处于栈展开（stack unwinding）过程中（比如另一个异常正在被处理），C++ 标准规定必须调用 std::terminate。这不是可选行为，而是强制终止——连 std::set_terminate 自定义的 handler 都救不回来（除非你把它设成空循环，但那只是掩盖问题）。
根本原因在于：栈展开本身依赖“每个析构函数都安全完成”，一旦某个析构函数中途抛出新异常，运行时无法决定该继续展开还是处理新异常，只能放弃。
- 即使析构函数是
noexcept(false)（C++11 默认），编译器仍会在栈展开期间隐式加上noexcept(true)约束 - Clang/GCC 在 -fexceptions 下会插入检查，发现栈展开中抛异常就跳转到
__cxa_call_unexpected→std::terminate - MSVC 同样遵循标准，行为一致
常见误用场景：资源释放里藏着 throw
最典型的是在析构函数里调用可能抛异常的接口，比如：
class FileWrapper {
FILE* fp;
public:
~FileWrapper() {
if (fp && fclose(fp) != 0) { // fclose 不抛异常，但类似 write()、sync() 可能封装了 throw 版本
throw std::runtime_error("close failed"); // ❌ 危险！
}
}
};更隐蔽的是间接调用：析构中调用某成员对象的函数、或通过智能指针的自定义 deleter 抛异常。
立即学习“C++免费学习笔记（深入）”；
- RAII 类型不该承担“报告错误”的职责，析构只做清理；错误应提前暴露（如
close()方法显式返回状态或抛异常） - 若必须反馈失败（如日志、监控），改用
std::abort()、std::quick_exit()或写入 stderr —— 但别 throw - std::ofstream 的析构函数是
noexcept，其内部 close 失败会被忽略（可通过rdbuf()->pubsync()提前检查）
noexcept 与编译器优化的关系
C++11 起，析构函数默认是 noexcept(true)。如果你手动声明为 noexcept(false)，编译器不会阻止你写 throw，但一旦在栈展开中触发，仍 terminate。
- 声明
~T() noexcept(false)只影响类型属性（如std::is_nothrow_destructible_v），不影响运行时安全机制 - 某些编译器（如 GCC 12+）在 -O2 下会对
noexcept析构函数做优化，省略异常栈帧注册；但一旦违反，崩溃更“干净”——没机会 catch - 模板类中若成员类型有
noexcept(false)析构函数，整个类的析构也会被推导为noexcept(false)，需留意传播
真正安全的错误处理替代方案
把“可能失败的清理动作”从析构函数里移出来，交给用户显式调用：
class DatabaseConnection {
sqlite3* db;
public:
~DatabaseConnection() noexcept { /* 只做非抛异常的 cleanup，如 db = nullptr */ }
[[nodiscard]] bool close() noexcept { // 显式关闭，返回成功与否
return sqlite3_close(db) == SQLITE_OK;
}
void force_close() { // 若必须确保释放，可用 abort + close
if (!close()) {
std::abort(); // 或记录后 exit(1)
}
}};
- std::unique_ptr 的自定义 deleter 必须是
noexcept，否则编译失败（这是编译期防护） - 如果底层 API 必须 throw（如某些 C++ 封装库），在 deleter 中 try/catch 并吞掉异常，或转换为 abort/log
- 单元测试中可故意让 close 报错，验证用户是否正确调用了显式清理，而不是依赖析构
核心不是“不能写 throw”，而是“栈展开中 throw 的后果不可恢复”。所有看似绕过规则的技巧（比如在析构里 setjmp/longjmp）都会破坏异常机制一致性，比 terminate 更难调试。
