子线程异常不会自动传至主线程，必须手动try-catch或用std::promise/std::future显式传递；未捕获异常将调用std::terminate导致线程静默终止，引发资源泄漏等问题。
子线程抛出的异常不会自动传给主线程，不加处理会导致线程直接终止、资源泄漏、甚至程序静默崩溃。必须在每个线程函数入口手动捕获，或通过 std::promise/std::future 显式传递异常。
每个线程函数必须自己 try-catch
这是最基础也最容易被跳过的一步。C++ 标准规定：未捕获的异常在子线程中会调用 std::terminate，而不是传播到主线程——结果是该线程直接退出，且不通知任何人。
常见错误现象：
- 主线程正常执行完，但子线程已静默退出，日志里没报错也没提示
- 使用
std::lock_guard时在加锁后抛异常，却忘了释放锁 → 其他线程永久阻塞 - 动态分配内存后抛异常，没走析构 → 内存泄漏
正确做法：
立即学习“C++免费学习笔记（深入）”；
- 把整个线程函数体包进
try块，catch(...)至少兜底（避免std::terminate） - 在
catch中做最小必要清理（如解锁、关闭句柄），再记录日志或上报状态 - 不要依赖 RAII 自动释放就省略
try-catch：RAII 只保证本线程栈展开，不解决线程间通信问题
用 std::promise 和 std::future 跨线程传递异常
当主线程需要感知子线程是否出错、以及具体错误信息时，不能靠“等线程结束再查标志位”，而应让异常本身可传递。这是唯一标准、可移植的跨线程异常转发机制。
关键点：
-
std::promise::set_exception()可以把当前异常对象（通过std::current_exception()获取）存入 promise -
std::future::get()在主线程调用时，若子线程存了异常，会直接 rethrow —— 这个异常就运行在主线程上下文中，能被正常catch - 必须确保
promise对象在线程启动前就构造好，并通过值传递或std::move给子线程（不能传引用或指针，避免生命周期问题）
示例片段（简化）：
std::promise<int> prom;
std::thread t([&prom] {
try {
// 可能抛 std::runtime_error
throw std::runtime_error("failed in worker");
} catch (...) {
prom.set_exception(std::current_exception());
}
});
auto fut = prom.get_future();
t.detach(); // 或 join，视需求而定
// 主线程中：
try {
fut.get(); // 这里会 rethrow 子线程的异常
} catch (const std::exception& e) {
std::cerr << "Caught: " << e.what() << '\n';
}
别踩这些坑
实际调试中最常卡住的地方：
-
std::thread构造后忘记join()或detach()：线程对象析构时若仍可 joinable，会调用std::terminate—— 这和异常无关，但常和异常处理逻辑混在一起导致误判 - 在
catch块里又抛新异常（比如日志失败）：没包第二层try-catch就会再次 terminate - 用
std::set_terminate替代try-catch：它只能全局拦截，无法获取异常对象、无法区分线程、无法做针对性恢复 - 把
std::exception_ptr存进全局容器再由主线程轮询：既非实时，又引入同步开销，还容易漏清理 —— 不如直接用future
真正麻烦的不是“怎么传异常”，而是“谁负责检查、在哪检查、检查后怎么响应”。future::get() 的阻塞语义和异常重抛行为，决定了它必须出现在你明确准备处理错误的位置；提前调用或忽略返回值，异常就又消失了。
