关键在于将异常限制在单个任务边界内：线程池不自动捕获异常，需分层设防——任务执行层主动try-catch兜底、结果获取层显式调用get()捕获原始异常、全局层面通过钩子（如afterexecute或set_terminate）监控未捕获异常，并保障流水线状态隔离。

关键在于把异常“关进笼子”，不让它逃出单个任务边界。线程池本身不自动捕获任务内抛出的异常，一旦未处理，轻则该线程终止、重则触发std::terminate（C++）或静默吞掉异常（Java），导致流水线看似正常实则漏数据、状态错乱。实战中需分层设防：在任务执行层兜底、在结果获取层捕获、在全局层面监控。

任务内部加壳：执行阶段主动拦截

这是最基础也最关键的防线。不能依赖调用方去try-catch，而要在任务被线程池真正执行时就完成捕获。

• C++中修改ThreadPool.h的入队逻辑，将原始(*task)()包装进try-catch块，捕获std::exception及未知异常，记录日志但不抛出
• Java中避免裸写Runnable，统一使用Callable<t></t>，并在call()方法内包裹全部业务逻辑，确保所有异常都转为返回值或存入Future
• 禁止在任务里直接抛出未声明的运行时异常而不处理；若必须抛出，应封装为自定义业务异常并明确记录上下文（如任务ID、输入参数摘要）

结果拉取时不隐忍：显式检查Future状态

提交任务获得Future（C++的std::future或Java的Future>）只是开始，真正捕获异常发生在调用get()时。这一步绝不能跳过或忽略返回值。

• 每次调用future.get()必须配对try-catch，捕获ExecutionException（Java）或std::exception（C++），从中提取原始异常原因
• 不要用isDone()或isCancelled()代替get()——它们不触发异常传播，无法得知任务是否失败
• 对批量任务，用CompletableFuture.allOf()或ExecutorService.invokeAll()统一收集结果，再遍历每个Future调用get()，逐个解析成败

全局钩子兜底：避免异常漏网

即使任务内部做了防护，仍可能有第三方库抛出未预期异常，或线程初始化失败等边缘情况。需设置第二道保险。

• Java中重写ThreadPoolExecutor.afterExecute(Runnable r, Throwable t)：当t != null，说明任务执行中未捕获异常已向上冒泡至此，立即记录完整堆栈并告警
• C++中可在工作线程主循环里设置std::set_terminate回调，仅作最后记录，不恢复执行；更推荐在worker线程函数入口加统一try-catch
• 为线程池配置ThreadFactory，在创建每个线程时设置UncaughtExceptionHandler，捕获线程级未处理异常

流水线状态隔离：失败不阻塞后续

异常处理的终极目标不是“消灭错误”，而是“控制影响”。要让一个任务失败，不影响其他任务的输入、处理、输出环节。

• 设计任务时遵循“无共享”原则：避免多个任务共用同一对象实例或静态变量，防止一个任务异常污染全局状态
• 使用不可变输入参数或深拷贝，确保任务失败后原始数据仍完好，可重试或降级处理
• 在流水线编排层（如用CompletableFuture.thenCompose()串联）中，用exceptionally()或handle()替代thenApply()，让异常分支独立走降级逻辑，不中断主链路