析构函数里抛异常是危险操作，C++11起默认为noexcept，若抛出异常且存在未捕获异常则调用std::terminate终止程序；根本原因是栈展开时无法安全处理多个活跃异常。
析构函数里抛异常是危险操作，C++11 起默认禁止，强制设为 noexcept；若硬要抛，程序直接调用 std::terminate 终止。
为什么析构函数不能抛异常
核心矛盾在于栈展开（stack unwinding）过程本身可能触发多个析构函数调用。一旦某个析构函数抛出异常，而当前已有未捕获的异常正在传播（比如外层函数刚 throw 了一个异常），C++ 标准规定此时必须终止程序——因为无法安全地同时处理两个活跃异常。
常见错误现象：
- 程序在
throw后崩溃，堆栈只显示std::terminate或abort，找不到原始异常点 - 调试时发现析构函数里
throw语句执行了，但没进 catch，直接进程退出 - 使用
std::vector或std::unique_ptr管理资源时，其内部析构若抛异常，上层完全无法干预
C++11 及以后的 noexcept 默认行为
从 C++11 开始，编译器自动为用户未显式声明异常规范的析构函数添加 noexcept(true)。这意味着：
立即学习“C++免费学习笔记（深入）”；
- 你写
~MyClass() { throw std::runtime_error("oops"); }，编译不报错，但运行时会触发std::terminate - 若想显式允许抛异常（极不推荐），必须写成
~MyClass() noexcept(false)，但这只在“确定不会发生栈展开”时才勉强可行（例如全局对象析构、且无其他异常在飞） - 继承体系中，基类析构若为
noexcept，派生类析构也自动继承该约束；违反会导致编译失败
如何安全地处理析构中的错误
资源清理逻辑不该依赖异常传递。正确做法是把可能失败的操作移出析构函数，或在析构中静默处理、记录日志、调用 std::abort（仅限严重错误）。
- 用 RAII 封装资源时，确保
close()、free()、unmap()等底层调用本身不抛异常；如有必要，用返回码或std::error_code替代 - 若必须报告错误（如日志写入失败），改用
std::cerr 或回调函数，而非throw - 测试时可临时开启
-fno-exceptions编译选项，提前暴露隐式异常路径
栈展开机制与实际影响
栈展开不是“逐层 try-catch”，而是语言级强制保证：只要进入异常传播路径，就按栈帧逆序调用所有已构造对象的析构函数。这个过程不可中断、不可跳过、不可重入。
- 若某析构函数中调用了另一个可能抛异常的函数（如
std::ofstream::close()），应先检查状态：if (file.fail()) { /* 记录，不 throw */ } - 智能指针（如
std::shared_ptr）的自定义删除器也受同样约束：不能抛异常 - 线程局部存储（TLS）对象析构若失败，同样触发
std::terminate，且难以调试
真正棘手的是那些看似无害、实则暗藏异常的调用——比如第三方库接口、STL 容器的 clear()、甚至 std::string 的销毁（如果其分配器抛异常）。别假设“析构函数很轻量”，先看它调用了什么。
