必须做异常处理，而且不能靠开发自觉，必须从「框架层做统一兜底」，否则一定会出现「任务静默失败、业务出问题查不到原因」的生产事故。
你之前看到的代码是简化配置版，生产落地必须补上异常处理；针对「开发忘了写」的问题，核心思路是人防不如技防：不依赖业务开发主动加 try-catch，而是在线程池底层做全局异常兜底，就算业务代码完全没做异常处理，也至少能保证「异常有日志、有告警、不会静默丢失」。
一、先理清：线程池的两类异常，坑完全不一样
很多人对线程池异常的认知是错的，以为异常会自动打印，实际分两种场景，坑点天差地别：
场景 1：任务提交阶段异常（拒绝异常）
触发时机：队列满、线程数达上限，触发拒绝策略时。
- 只有默认的
AbortPolicy会直接抛出RejectedExecutionException运行时异常； CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy都不会抛出异常，要么主线程执行、要么静默丢弃。
坑点：如果用了 AbortPolicy，提交任务的地方没捕获异常，会直接把提交线程（比如 Tomcat 请求线程）打挂，导致接口直接报错、前端 500。
场景 2：任务执行阶段异常（业务代码异常）
触发时机：Runnable/Callable 内部的业务代码抛出空指针、超时、下游异常等。 这是 90% 生产事故的重灾区，核心坑是：异常会被线程池 “吞掉”，业务静默失败，开发完全感知不到。
两个提交方式的天差地别（90% 开发踩过）
表格
| 提交方式 | 异常表现 | 能不能被全局捕获 | 坑点 |
|---|---|---|---|
execute(Runnable) | 任务抛异常会终止当前工作线程，异常打印到标准错误流 | 能，可被afterExecute、UncaughtExceptionHandler捕获 | 不配置兜底的话，异常只打控制台，生产可能漏采集 |
