Future.get() 抛出的 ExecutionException 封装了任务的真实异常，必须通过 getCause() 获取原始错误；正确做法是捕获 InterruptedException、提取 ExecutionException 的 cause 并记录完整异常链。
在Java并发编程中，ExecutionException 和 Future.get() 的异常处理是常见但容易出错的部分。当你通过 Future 获取异步任务结果时，任何在任务执行过程中抛出的异常都会被封装并重新抛出，理解这一点对正确处理错误至关重要。
Future.get() 可能抛出的异常类型
Future.get() 方法在调用时可能抛出以下几种异常：
- InterruptedException：当前线程在等待结果时被中断。
-
ExecutionException：任务执行过程中抛出了异常，这个异常会被包装成
ExecutionException抛出。 -
CancellationException：如果任务被取消（例如调用了
cancel(true)），再调用get()就会抛出此异常。
其中，ExecutionException 是最关键的——它不是真正的错误源，而是“异常的容器”。
ExecutionException 包装了真正的异常
当一个 Callable 或 Runnable 在线程池中执行失败时，比如发生 NullPointerException 或 IOException，这些异常不会直接抛给调用 get() 的线程，而是被封装在 ExecutionException 中。
立即学习“Java免费学习笔记（深入）”；
示例代码：ExecutorService executor = Executors.newSingleThreadExecutor();
Future<Integer> future = executor.submit(() -> {
throw new RuntimeException("任务内部出错");
});
try {
Integer result = future.get();
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
} catch (ExecutionException e) {
Throwable cause = e.getCause(); // 获取原始异常
System.out.println("真实异常: " + cause.getMessage());
}
在这个例子中，虽然抛出的是 RuntimeException，但在 get() 调用时捕获的是 ExecutionException，必须通过 getCause() 才能看到真正的问题。
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
如何正确处理 Future 异常
为了写出健壮的异步代码，建议统一按以下方式处理 Future.get()：
- 始终将
get()放在 try-catch 块中。 - 优先处理
InterruptedException，并考虑是否需要中断传播。 - 从
ExecutionException中提取cause并根据业务需要记录或处理。 - 如果是可恢复错误，可以重试；如果是编程错误（如空指针），应记录日志并防止扩散。
如果任务本身预期会抛出检查异常（如 IOException），也可以在 Callable 中捕获后重新抛出，这样仍会被包装进 ExecutionException，但 getCause() 会返回原异常。
避免忽略 ExecutionException 的最佳实践
常见的错误是只打印 ExecutionException 自身而忽略了 cause，导致日志中看不到真实原因。正确的做法是：
} catch (ExecutionException e) {
Throwable realCause = e.getCause();
if (realCause instanceof MyBusinessException) {
// 处理业务异常
} else {
// 记录完整堆栈，包括 cause
log.error("任务执行失败", e); // 推荐：打印整个异常链
}
}
使用日志框架时传入整个异常对象（而不是只打 message），能确保 cause 的堆栈也被输出。
基本上就这些。只要记住：Future.get() 的 ExecutionException 是“异常包装器”，真正的错误藏在 getCause() 里，别忘了拆开看。
