future.get() 抛出 executionexception 是因规范要求将子线程异常封装后上抛，避免线程间未检查异常直传；其 cause 即原始异常，最多一层嵌套，interruptedexception 和 cancellationexception 则直接抛出。
Future.get() 为什么抛出的是 ExecutionException 而不是原始异常
因为 Future.get() 的设计契约就是把任务执行中抛出的任何异常都封装进 ExecutionException，再往上扔。这不是 bug，是规范行为——JVM 不允许线程间直接“透传”未检查异常，必须包装一层。
常见错误现象：Future.get() 报错堆栈里看不到你业务代码里 throw new IllegalArgumentException("xxx") 的原始位置，只看到最外层的 ExecutionException 套着 Cause: IllegalArgumentException。
- 所有子线程内未捕获的异常（包括
RuntimeException和Error）都会被ThreadPoolExecutor捕获并塞进ExecutionException的cause -
FutureTask是实际做这层包装的类，它在report()方法里构造ExecutionException - 如果你用的是
CompletableFuture，默认行为不同：它的get()仍走ExecutionException，但join()会直接抛原始异常（这点容易踩坑）
怎么从 ExecutionException 里拿到原始异常（且不写 try-catch 套娃）
别层层 getCause().getCause() 手动剥——ExecutionException 的 cause 就是你要的原始异常，最多一层嵌套。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
e.getCause() != null ? e.getCause() : e安全取原始异常，避免空指针（某些极端情况cause可能为null） - 如果想统一处理，写个工具方法：
Throwable unwrapExecutionException(Throwable t)，内部判断是否为ExecutionException或CompletionException并返回cause - 注意
InterruptedException和CancellationException是特例：它们不会被包装，会直接从get()抛出，和ExecutionException平级
CompletableFuture.join() 和 get() 的异常行为差异
join() 看起来更“透明”，但它抛的是 CompletionException，而这个异常的 cause 才是原始异常——表面省了一层，底层还是包装，只是类型不同。
使用场景对比：
- 用
get()：需要响应中断（比如超时控制），必须处理InterruptedException和TimeoutException - 用
join()：不关心中断，只想要“失败即失败”，但要注意它不响应中断，调用线程被阻塞时无法被Thread.interrupt()打断 - 两者对
RuntimeException的原始堆栈都保留完整，但join()的异常类型不是你代码里 throw 的那个，所以instanceof判断会失败
自定义 Future 实现时如何避免异常丢失或二次包装
如果你自己实现 Future（比如封装 RPC 调用），千万别在 get() 里 new 一个新异常 throw 出去——这会丢掉原始堆栈。
关键点：
- 保存原始异常要用
initCause()或构造时传入cause，确保printStackTrace()能展开到业务代码行 - 不要 catch 住异常再 throw 新的
RuntimeException，除非你显式把原异常设为 cause - 如果底层是异步回调（比如 Netty ChannelFuture），回调里抛异常不会自动进
Future.get()，得手动调用setException()（如DefaultPromise提供的方法）
复杂点在于：异常透明化不是靠“不包装”，而是靠“正确包装”。漏掉 cause、多包一层、或者用错异常类型（比如该用 ExecutionException 却用了 RuntimeException），都会让下游排查时卡在第一层堆栈。
