析构函数不可抛异常，否则触发std::terminate；应将可能失败的操作移至显式方法（如close()），析构函数仅执行确定成功操作。
析构函数里别 throw，这是 C++ 的硬性约束
析构函数抛异常直接触发 std::terminate，不是 bug，是标准行为。C++11 起默认给所有析构函数加了隐式 noexcept(true)，一旦抛出异常，程序立刻终止——连栈展开都跳过。这不是编译器警告，是运行时铁律。
常见错误现象：看似“安全”的清理逻辑突然崩溃
比如在析构函数里调用可能失败的系统 API（close()、fclose()）、释放网络连接、写日志到磁盘，或者调用了某个第三方库的“清理接口”，而它内部可能 throw。这些代码在单元测试里可能不触发异常，但在线上高负载或资源紧张时就崩。
-
std::ofstream析构时如果文件写入失败，默认静默丢弃错误，但若你重载了std::streambuf并在sync()里 throw，就踩雷 - 自定义 RAII 类中，在析构里调用
sqlite3_close_v2()后检查返回值并 throw，哪怕只在调试模式启用，也会导致std::terminate - 使用
std::thread对象未join()或detach()就析构，其析构函数会调用std::terminate—— 这虽不是“throw”，但同属析构期不可恢复错误
修复方案：把可能失败的逻辑移出析构函数
核心原则：析构函数只做“一定成功”的事（如置空指针、释放已知有效句柄、解绑回调）。所有带失败风险的操作，必须暴露为显式成员函数，由用户决定何时调用、如何处理错误。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 提供
close()、shutdown()、flush()等方法，返回bool或std::error_code，让调用者自己try/catch或检查错误 - 析构函数内只做“尽力而为”：调用上述方法，但忽略其返回值；或仅对确定不会失败的操作（如
delete ptr、munmap()）执行 - 如果必须记录错误，改用异步日志（如写入无锁 ring buffer），避免在析构中做 I/O 或内存分配
- 禁用隐式
noexcept？不行。显式写~MyClass() noexcept(false)在 C++11 及以后是 ill-formed（编译报错），不要尝试
兼容性与性能影响：为什么不能“捕获并吞掉”
有人想在析构里 try/catch 吞掉异常，这看似绕过 std::terminate，但极其危险：
- 若析构函数本身是栈展开过程中被调用（比如另一个异常正在传播），此时再抛异常会直接 terminate；而 catch 后继续执行，可能破坏对象状态一致性
- 吞掉错误等于掩盖资源泄漏或数据损坏，线上问题更难定位
- 现代编译器对
noexcept函数有优化（如省略栈展开信息），强行打破会轻微影响性能，更重要的是丧失异常传播语义的可预测性
真正复杂的点在于：很多旧代码把“清理”和“错误处理”混在一起写，重构时得拆开生命周期管理与错误恢复路径。这点容易被忽略——不是不会写 noexcept，而是没意识到“析构即销毁”和“关闭即可能失败”本就是两个正交职责。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
