C++ try-catch机制本身稳定但不等于安全，问题多源于开发者对异常生命周期、类型匹配和资源管理的误用；推荐按具体异常类型分层捕获，优先使用const std::exception&而非catch(...)以保留类型信息和上下文。
直接说结论：C++ 的 try-catch 机制本身是稳定的，但“稳定”不等于“安全”——真正出问题的，几乎全是开发者对异常对象生命周期、抛出/捕获类型匹配、资源管理逻辑的误用。
为什么 catch(std::exception& e) 比 catch(...) 更可靠
用 catch(...) 看似兜底，实则丢弃了所有类型信息和错误上下文。它无法调用 e.what()，也无法区分是 std::runtime_error 还是自定义异常，更没法做针对性恢复逻辑。
推荐写法：
try {
risky_operation();
} catch (const std::runtime_error& e) {
// 处理运行时错误（如文件打开失败）
log_error("Runtime error: ", e.what());
} catch (const std::logic_error& e) {
// 处理逻辑错误（如断言失败、无效参数）
abort_on_bug(e.what());
} catch (const std::exception& e) {
// 兜底：所有继承自 std::exception 的异常
std::cerr << "Unexpected std::exception: " << e.what() << "\n";
}
- 始终用
const&捕获，避免异常对象被意外拷贝或修改 - 不要在
catch块里抛出新异常，除非你明确要向上委托（此时应throw;而非throw e;，否则会切片） -
catch(...)只应在最外层（如main()）做日志+退出，且必须紧接在std::exception捕获之后
throw 表达式中返回局部对象？危险！
常见错误写法：throw std::runtime_error("msg"); 是安全的，但下面这个不是：
立即学习“C++免费学习笔记（深入）”；
std::runtime_error make_error() {
std::string msg = "file not found";
return std::runtime_error(msg.c_str()); // ❌ msg 已析构，c_str() 悬空
}
问题本质：抛出的是临时对象，但若构造函数内部引用了即将销毁的栈变量，就会导致未定义行为。
- 确保所有传给异常构造函数的字符串、缓冲区等，在异常对象构造完成前仍有效
- 优先用字面量字符串（
"xxx"）或std::string值传递（C++11 后移动语义可避免深拷贝） - 自定义异常类务必在成员中持有完整数据（如用
std::string m_msg;，而非const char*）
noexcept 与异常规范的实际影响
声明 noexcept 不仅是文档说明，它直接影响编译器优化和栈展开行为。一旦标为 noexcept 的函数抛出异常，程序会立即调用 std::terminate()，不会进入任何 catch 块。
- 移动构造函数、交换函数（
swap）、析构函数默认隐式noexcept，若你手动实现它们，务必显式加noexcept或确认可能抛异常 - 不要给可能抛异常的函数乱加
noexcept，尤其涉及new、std::string构造、I/O 的场景 - 用
noexcept(expr)检测表达式是否可能抛异常（如noexcept(std::move(x))），比硬编码更健壮
异常处理真正的复杂点不在语法，而在于：异常发生时，栈上所有已构造对象的析构顺序是否可控、资源释放是否完备、以及 catch 块自身是否可能再抛异常。这些细节一旦出错，就不是“不稳定”，而是不可预测的崩溃或资源泄漏。
