CompletableFuture的异步异常无法被外层try-catch捕获，因异常被静默封装为CompletionException存于future内部，需通过get()、exceptionally、handle等方法显式处理。
直接用 try-catch 包裹 CompletableFuture 的创建或链式调用，基本捕不到异步任务里抛出的异常——因为异常发生在另一个线程里，主线程的 try-catch 作用域根本覆盖不到。
异常不会自动向上冒泡到外层 try-catch
CompletableFuture 内部执行的任务（比如 supplyAsync 中的逻辑）是在 ForkJoinPool 或自定义线程池中运行的。一旦那里抛出 RuntimeException 或 checked exception，它会被包装成 CompletionException，并**静默存入该 future 实例内部**，而不是中断当前主线程执行流。
这意味着：
- 你在 supplyAsync 外写 try-catch，对里面的异常完全无效
- future.get() 时才会把 CompletionException 抛出来，但此时已脱离原始业务上下文
- 如果一直不 get，异常就“消失”了，日志没打、监控没报、流程却卡在某个 then 阶段不动
无法区分不同阶段的异常来源
一个完整链路可能包含多个异步步骤：获取用户 → 查询订单 → 聚合统计。每个环节都可能失败。传统 try-catch 只能包裹整个链的构造过程，没法定位是哪一步出错，更无法为每一步定制恢复策略。
立即学习“Java免费学习笔记（深入）”；
例如：
- 用户服务超时 → 应返回缓存用户
- 订单查询空结果 → 可继续走默认逻辑
- 聚合时 NPE → 必须告警并终止
这些差异化处理，靠外层一个 catch 块根本做不到。
阻塞式 get() 破坏异步优势
很多开发者发现异常没被捕获，就退而求其次，在链尾加 future.get()，再套 try-catch。这看似“解决问题”，实则让异步变成伪异步：
- 主线程被阻塞，失去非阻塞响应能力
- 无法利用 thenApply/thenAccept 等回调做后续编排
- 超时控制需手动处理 TimeoutException，代码臃肿
缺少对“成功与失败统一收口”的支持
同步代码里，你可以在 finally 做清理，在 catch 里记录日志；但在 CompletableFuture 链中，没有天然的“无论成功或失败都执行”的位置——除非用 whenComplete，但它不改变结果，也不能返回新值；而 exceptionally 又只管失败，不管正常路径。
真正需要的是像 handle 这样既能拿到 result 又能拿到 throwable 的统一处理器，但 try-catch 完全不具备这种表达力。
