捕获executionexception后必须调用getcause()获取原始异常，同时不可遗漏interruptedexception和timeoutexception；标准处理结构为：try调用get()，catch三类异常分别处理，否则异常可能被吞没。
捕获ExecutionException本身只是第一步，关键是要拿到它包裹的原始异常——也就是任务内部真正出问题的地方。直接 catch 住 ExecutionException 却不调用 getCause()，等于只看了病历封面，没看诊断报告。
必须捕获并拆解 getCause()
ExecutionException 是个“壳”，它的作用是把异步线程里抛出的异常安全地传回主线程。真正要处理的，永远是 e.getCause() 返回的那个 Throwable：
- 它可能是 NullPointerException、IllegalArgumentException 等运行时异常
- 也可能是 SQLException、IOException 等受检异常
- 还可能是你自定义的 BusinessException 或 ValidationException
- 极少数情况下 cause 为 null，建议判空保护
别漏掉 InterruptedException 和 TimeoutException
Future.get() 一共可能抛出三种异常，缺一不可：
- ExecutionException：任务执行中出错 → 拆解 cause 分类处理
- InterruptedException：等待被中断 → 调用 Thread.currentThread().interrupt() 恢复中断状态，再决定是否退出或重试
- TimeoutException：显式超时（如 get(5, SECONDS)）→ 属于流程控制问题，适合降级、告警或重试，不是业务异常
推荐的标准写法结构
一个健壮的 get() 调用应该长这样：
- 用 try 包裹 future.get()
- catch ExecutionException → 取 cause，用 instanceof 判断类型，按业务逻辑分别响应
- catch InterruptedException → 恢复中断，通常抛运行时异常或返回默认值
- catch TimeoutException → 单独处理，比如返回缓存、空结果或触发熔断
为什么异常容易“消失”？
如果不调用 get()，submit() 返回的 Future 会默默把异常藏起来；如果用 execute() 提交 Runnable，异常甚至不会进 Future，而是直接被线程吞掉。所以：
- 用 submit() + get() 是最直接可控的方式
- 若不用 get()，就得靠自定义 ThreadFactory 设置 UncaughtExceptionHandler
- CompletableFuture 更灵活，可用 exceptionally() 或 handle() 链式捕获，避免手动拆包
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
