std::thread无法传递异常到主线程，未捕获异常会直接调用std::terminate终止程序；应改用std::async+std::future，其get()可原样重抛子线程异常。
std::thread 无法直接传递异常到主线程
主线程捕获不到 std::thread 内抛出的未处理异常——C++ 标准规定，如果线程函数退出时带有未捕获异常，会调用 std::terminate，程序直接终止。这不是“传递失败”，而是根本没机会传递。
常见错误现象：std::terminate called without an active exception 或直接崩溃，调试时发现异常根本没走到主线程的 catch 块里。
- 不要在线程函数里裸 throw；必须显式捕获并转存
-
std::thread本身不提供异常转发机制，得靠手动封装 - 若用
std::async（带std::launch::async），它内部已封装了异常传播逻辑，是更省心的选择
用 std::async + std::future 获取线程异常
std::async 是最直接的解法：它把线程执行结果（含异常）封装进 std::future，主线程调用 get() 时，若子线程抛过异常，会原样 rethrow 到主线程上下文。
示例：
立即学习“C++免费学习笔记（深入）”；
auto fut = std::async(std::launch::async, [] {
throw std::runtime_error("from worker");
});
try {
fut.get(); // 这里会抛出 runtime_error
} catch (const std::exception& e) {
std::cout << e.what() << "\n"; // 正确捕获
}
- 必须用
std::launch::async（或默认策略），否则可能延迟执行甚至不启新线程 -
fut.get()是阻塞调用，且只能调用一次；重复调用会抛std::future_error - 异常类型完全保留，包括自定义异常类的完整信息和栈语义
手动用 std::promise/std::future 传递异常
当需要更精细控制线程生命周期（比如用 std::thread 启动，但又想传异常），就得自己配 std::promise。核心是在线程函数内用 promise.set_exception() 显式存异常。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操要点：
- 声明
std::promise<T>（T 是期望返回类型，如int），然后通过get_future()拿到std::future<T> - 在线程函数中，必须 try/catch 所有可能异常，并在 catch 块里调用
promise.set_exception(std::current_exception()) - 主线程仍靠
future.get()触发 rethrow，行为与std::async一致
漏掉 std::current_exception() 或忘记 set_exception()，异常就丢了，线程仍会 terminate。
std::jthread（C++20）不能自动传异常
别被名字误导：std::jthread 只是给 std::thread 加了自动 join 和停止令牌支持，它不改变异常传播规则。线程内未捕获异常照样 terminate。
也就是说，即使你用了 C++20，该封装 promise 的还得封装，该用 async 的还是优先 async。
真正容易被忽略的是：异常传播不是线程模型的默认能力，而是需要明确选择通信载体（future）+ 显式错误路径（set_exception 或 async 的隐式封装）。一旦选错载体或漏写 catch，程序就不是“处理不了异常”，而是“根本没给异常留活路”。
