必须用 catch(...) 仅在三处：main() 末尾兜底防终止、C 接口函数内防异常跨语言传播、调试时配合 std::current_exception() 日志；它不提供异常信息，不能替代具体类型捕获。
直接回答：C++ 中用 catch(...) 可以捕获所有异常，但它不提供异常对象，无法知道抛出的是什么类型，也不能安全地处理或记录细节——它只该作为最后一道防线，绝不能替代具体类型的 catch。
什么时候必须用 catch(...)
仅在以下场景中合理使用：
- 在
main()函数末尾兜底，防止未处理异常导致程序直接终止（尤其是嵌入式或服务进程） - 在 DLL / SO 的 C 接口函数内部，避免 C++ 异常跨语言边界传播（C 不认识异常）
- 在调试阶段临时捕获未知异常，配合
std::current_exception()做日志（需 C++11+）
其他地方写 catch(...) 通常意味着你还没想清楚错误分类，或者故意掩盖问题。
catch(...) 为什么不能代替 catch(const std::exception& e)
根本区别在于信息丢失：
立即学习“C++免费学习笔记（深入）”；
-
catch(const std::exception& e)能调用e.what()，至少拿到错误描述字符串 -
catch(...)连异常类型名都拿不到，typeid(e).name()不可用（e 根本不存在） - 无法做类型判断（比如区分
std::bad_alloc和std::runtime_error），更没法针对性重试或降级 - 若在析构函数里抛异常，又用
catch(...)吞掉，可能掩盖双重异常崩溃（std::terminate）
想“安全地”捕获所有异常？别靠 catch(...) 硬扛
真正健壮的做法是分层处理：
- 优先写明确的
catch块：比如catch(const std::bad_alloc&)、catch(const std::system_error&) - 再加一层
catch(const std::exception& e)处理标准库异常，统一记录e.what()和std::current_exception() - 最后才放
catch(...)，且必须立刻调用std::abort()或std::terminate()，而不是静默吞掉 - 若真需要重构异常内容，用
std::current_exception()+std::rethrow_exception()在catch(...)里转成已知类型（但开销大，慎用）
示例片段（main 函数兜底）：
int main() {
try {
run_app();
} catch (const std::exception& e) {
log_error("std::exception: ", e.what());
return 1;
} catch (...) {
log_error("unknown exception — aborting");
std::abort(); // 不推荐 exit(1)，因不调用全局对象析构
}
}
容易被忽略的风险点
catch(...) 看似简单，但几个细节常被跳过：
- 它**不捕获信号**（如 SIGSEGV、SIGABRT），Unix/Linux 下仍需
signal()或sigaction()协同处理 - 在多线程中，每个线程需独立设置
catch(...)，主线程的兜底对子线程无效 - 某些编译器（如 MSVC）在 `/EHsc` 模式下，
catch(...)可能捕获结构化异常（SEH），但这是非标准行为，跨平台不可靠 - 若异常对象构造失败（比如拷贝构造函数抛异常），
catch(...)也救不了——此时已进入未定义行为
健壮性不来自“全捕获”，而来自对已知错误路径的显式覆盖和对未知错误的快速、可诊断的失败。
