ExecutionException 是 Future.get() 包装任务内部异常的容器，必须调用 getCause() 获取原始异常；CompletableFuture 用 exceptionally/handle 可直接处理原始异常，避免包装。
ExecutionException 为什么总是包装了一层？
ExecutionException 本身不是你代码里直接抛出的异常，而是 Future.get() 在任务执行出错时，把底层真实异常“包”进来的容器。它存在的唯一目的，就是告诉调用方：「这个 Future 没成功，原因藏在 getCause() 里」。
常见错误现象是直接打印或捕获 ExecutionException 却没调用 getCause()，结果日志里只看到 java.util.concurrent.ExecutionException，完全看不出到底是 NullPointerException 还是 SQLException。
- 所有通过
ExecutorService.submit(Runnable)或submit(Callable)提交的任务，一旦执行中抛出未捕获异常，Future.get()就会以ExecutionException包装后抛出 -
FutureTask、CompletableFuture（非handle/exceptionally场景）也遵循同一规则 - 注意：
CompletableFuture.runAsync(...).join()同样会把原始异常包成ExecutionException，但completeExceptionally()主动设置的异常不会被再包装
get() 调用时怎么安全提取原始异常？
别写 catch (ExecutionException e) { log.error(e); } —— 这等于放弃诊断线索。必须立刻调用 e.getCause()，并按实际类型做分支处理。
try {
String result = future.get();
} catch (ExecutionException e) {
Throwable cause = e.getCause();
if (cause instanceof IllegalArgumentException) {
// 处理参数错误
log.warn("业务参数异常", cause);
} else if (cause instanceof IOException) {
// 处理 IO 故障
log.error("远程调用失败", cause);
} else {
// 兜底：未知异常，保留堆栈
log.error("未预期的任务异常", cause);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
log.warn("任务等待被中断");
}
关键点：
立即学习“Java免费学习笔记（深入）”；
-
getCause()返回的是原始异常对象，类型就是你在 Callable 里throw的那个 - 如果原始异常是
Error（如OutOfMemoryError），getCause()也会原样返回，不会被过滤 - 不要忽略
InterruptedException：它和ExecutionException是并列的，不是子异常
CompletableFuture 怎么绕过 ExecutionException 包装？
如果你用的是 CompletableFuture，其实可以完全避开 ExecutionException —— 只要不用 get()，改用异步回调方式处理异常。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
future.handle((result, ex) -> {
if (ex != null) {
// ex 就是原始异常，无需 getCause()
if (ex instanceof TimeoutException) {
return "fallback";
}
throw new RuntimeException(ex);
}
return result;
});
或者更常用：
future.exceptionally(ex -> {
// ex 是原始异常，类型明确
if (ex instanceof BusinessException) {
return defaultResult();
}
log.error("任务失败", ex);
return null;
});
注意：
-
exceptionally()和handle()接收的ex参数就是原始异常，没有包装 - 但如果你仍调用
future.get()或future.join()，就又掉回ExecutionException的坑里 -
join()抛出的是CompletionException（包装逻辑类似，但继承自RuntimeException），它的getCause()也是原始异常
线程池拒绝任务时会不会抛 ExecutionException？
不会。ExecutionException 只跟「任务已提交且开始执行但中途失败」有关。如果任务根本没被执行（比如线程池已关闭、队列满被拒绝），submit() 本身就会立即抛出 RejectedExecutionException，根本不会生成 Future 对象。
所以你永远看不到这样的组合：
-
RejectedExecutionException→Future.get()→ExecutionException - 真正流程是：
submit()直接炸了，连Future都没拿到，自然谈不上get()
容易被忽略的一点：有些封装工具类（比如 Spring 的 @Async）会在代理层把 RejectedExecutionException 也转成 ExecutionException 再抛，这时候就要看具体框架行为，不能默认认为所有 ExecutionException 都来自任务内部。
