C++的try-catch只能捕获用throw显式抛出的异常及标准库中明确声明会抛异常的函数（如std::vector::at()、std::stoi()）所抛出的异常。
try-catch 能捕获哪些异常
C++ 的 try-catch 只能捕获用 throw 显式抛出的异常，以及标准库中明确声明会抛异常的函数（比如 std::vector::at()、std::stoi()）所抛出的异常。它**不能捕获**段错误（SIGSEGV）、除零（非浮点除零）、空指针解引用、栈溢出等底层运行时错误——这些属于操作系统信号或未定义行为，不是 C++ 异常机制的一部分。
常见误判：看到程序崩溃就以为“没 catch 到”，其实根本没进 try 块，因为崩溃发生在异常机制之外。
- 可捕获：
throw std::runtime_error("oops")、std::stoi("abc")抛出的std::invalid_argument - 不可捕获：
int* p = nullptr; *p = 42;、int x = 1 / 0;（整数除零是未定义行为，不抛异常） - 浮点除零可能产生
std::numeric_limits或触发 FPU 异常，但默认不抛 C++ 异常::quiet_NaN()
catch 块怎么写才不漏掉异常
关键不是“抓得全”，而是“抓得准+兜得住”。直接写 catch(...) 看似万能，但会吞掉所有信息，无法区分错误类型，也不利于调试和恢复逻辑。
推荐分层捕获：
立即学习“C++免费学习笔记（深入）”；
- 优先按具体类型捕获：例如
catch(const std::out_of_range& e)，可安全访问e.what() - 再捕获其父类（如
std::runtime_error），覆盖更广的运行时错误 - 最后用
catch(const std::exception& e)收口——这是标准异常的根类，能捕获所有从std::exception派生的异常 -
catch(...)仅用于日志记录+紧急清理，之后通常应重新抛出（throw;）或终止程序，避免静默失败
注意：catch(std::exception e)（传值）会触发拷贝，且可能切片；务必写成 catch(const std::exception& e)（常量引用）。
throw 表达式里该 throw 什么
不要 throw 原始字符串字面量（如 throw "file not found"），它不是 std::exception 派生类，会被 catch(const std::exception&) 漏掉，只能靠 catch(...) 或 catch(const char*) 捕获，破坏类型安全。
标准做法是 throw 标准异常对象或自定义异常类：
- 逻辑错误：用
std::logic_error及其子类（std::invalid_argument、std::domain_error） - 运行时问题：用
std::runtime_error及其子类（std::system_error、std::ios_base::failure） - 自定义异常：继承
std::runtime_error，构造时传入描述字符串，确保兼容现有 catch 链
示例：throw std::runtime_error("failed to open config file: " + filename);
异常安全的资源管理怎么做
异常发生时，栈展开（stack unwinding）会自动调用局部对象的析构函数——这是 RAII 的基础。但如果你手动 new 内存、fopen 文件、pthread_mutex_lock 锁，又没在 catch 里配对释放，就会泄漏。
正确姿势只有一条：别裸写资源管理代码。
- 用
std::unique_ptr替代裸new/delete - 用
std::fstream替代FILE*（析构自动fclose） - 用
std::lock_guard或std::scoped_lock包裹互斥锁 - 避免在构造函数里做可能失败的重操作；若必须，确保构造函数要么成功，要么彻底失败（不留下半构造对象）
函数是否异常安全，取决于它是否满足基本保证（资源不泄漏）、强保证（回滚到之前状态）或不抛保证（noexcept）。标 noexcept 不是装饰，一旦违反会调用 std::terminate。
真正容易被忽略的是：析构函数里不要抛异常。C++ 标准规定，若栈展开期间另一个异常被抛出（比如析构函数里 throw），直接调用 std::terminate。所以析构函数应全部标记为 noexcept（默认就是），且内部用错误码或日志处理失败。
