Java中的ExecutionException与Future异常处理_技术教程

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("任务等待被中断");
}

关键点：

getCause() 返回的是原始异常对象，类型就是你在 Callable 里 throw 的那个
如果原始异常是 Error（如 OutOfMemoryError），getCause() 也会原样返回，不会被过滤
不要忽略 InterruptedException：它和 ExecutionException 是并列的，不是子异常

CompletableFuture 怎么绕过 ExecutionException 包装？

如果你用的是 CompletableFuture，其实可以完全避开 ExecutionException —— 只要不用 get()，改用异步回调方式处理异常。

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 都来自任务内部。