catch(...)能捕获所有类型异常但不提供异常信息，仅用于兜底日志或资源清理，须配合catch(const std::exception&)使用，不可替代后者；std::set_terminate用于终止前收尾，非恢复执行。
catch(...) 能捕获哪些异常
它能捕获所有类型异常，包括 int、char*、自定义类对象，甚至 C++ 标准库没继承 std::exception 的异常（比如某些编译器抛出的 std::bad_cast 在特定 ABI 下可能不完全符合规范）。但它**不提供异常值信息**，无法知道抛了什么、为什么抛。
常见错误现象：catch(...) 后直接返回或静默吞掉异常，导致问题难以定位；或在 catch(...) 里试图用 dynamic_cast 强转，结果失败——因为根本不知道原类型。
- 只在兜底日志或资源清理场景使用，例如函数末尾的
catch(...)记录“未知异常”，然后重新抛出 - 不要把它当作
catch(const std::exception& e)的替代品 - 若需诊断，必须配合栈回溯（如
backtrace()）或调试器断点
为什么不能只靠 catch(const std::exception& e)
std::exception 只是标准异常的基类，但 C++ 允许抛任意类型。很多实际场景会跳出这个体系：第三方库用 throw "error"、Windows SEH 异常（通过 /EHa 混合捕获时）、甚至 std::terminate() 触发前的未捕获异常。
典型使用场景：写库函数接口时，你希望对标准异常做统一处理（如记录 e.what()），但又不能让非标准异常穿透出去导致进程崩溃。
立即学习“C++免费学习笔记（深入）”；
- 推荐组合：先
catch(const std::exception& e)处理已知语义异常 - 再
catch(...)做最后保障，并调用std::abort()或std::terminate()显式终止（避免静默失败） - 注意：
catch(const std::exception& e)不会捕获throw 42或throw nullptr
std::set_terminate 配合 catch(...) 的真实用途
当所有 catch 块都未能捕获异常（包括 catch(...) 之外的栈展开失败），程序会调用 std::terminate()，默认行为是调用 std::abort()。你可以用 std::set_terminate() 安装自定义终止处理器。
这不是为了“恢复执行”，而是为了在进程退出前做关键收尾：刷新日志缓冲区、生成 minidump、关闭句柄。
- 自定义 terminate handler 中禁止抛异常、禁止调用大多数 STL 函数（处于栈展开不可控状态）
- 可安全调用
write()、signal()、abort()等异步信号安全函数 - 示例中常见错误：在 terminate handler 里调用
std::cout << ...—— 此时流对象可能已被析构
实际项目中该选哪个捕获方式
没有银弹。关键看责任边界和可观测性要求。
服务主循环（如网络请求处理）建议三层捕获：
- 最内层：按业务逻辑
catch(const MyAppError& e)做重试或降级 - 中间层：用
catch(const std::exception& e)统一记录e.what()和上下文 ID - 最外层：仅一个
catch(...)，记录“未知异常”，调用std::abort()并触发 core dump
容易被忽略的是：catch(...) 无法区分是程序 bug 还是外部干扰（如内存损坏、信号中断）。所以真正健壮的服务，得靠 ASan/UBSan 编译选项 + coredump 分析，而不是依赖 catch 块兜底。
