exceptionally仅捕获前一异步阶段抛出的异常，不具全局兜底能力；它只在上游明确失败时执行，接收throwable并返回同类型值，无法获取正常结果，与handle相比更专一但灵活性低。
exceptionally 回调只捕获上一个异步阶段的异常
exceptionally 不是全局异常兜底，它只响应紧挨着它的前一个 CompletableFuture 阶段抛出的异常。如果前面用了 thenApply 且没抛异常，那后面的 exceptionally 根本不会触发。
- 常见错误现象：
exceptionally完全没执行，但程序却报了CompletionException—— 很可能是因为异常发生在更早的链路里，或者被中间某个阶段吞掉了 - 正确使用场景：专用于处理前一步计算（比如
supplyAsync或thenCompose）明确抛出的异常，不是用来替代 try-catch 的 - 参数差异：
exceptionally接收一个Function<throwable t></throwable>，返回值类型必须和上游阶段一致；不能改变返回类型，否则编译不通过
exceptionally 和 handle 的关键区别在哪
handle 是更通用的回调，无论上游成功还是失败都会执行；而 exceptionally 只在失败时运行，且不暴露正常结果值。
- 性能影响：两者开销接近，但
handle多一次函数调用判断，实际差异可忽略 - 兼容性：都从 Java 8 开始支持，无版本风险
- 容易踩的坑：误以为
exceptionally能拿到原始输入参数——它只能访问异常对象，不像handle同时接收(result, throwable) - 示例对比：
CompletableFuture.supplyAsync(() -> { throw new RuntimeException("boom"); })
.exceptionally(t -> "fallback"); // ✅ 返回 String，类型匹配
CompletableFuture.supplyAsync(() -> "ok")
.exceptionally(t -> "fallback"); // ❌ 永远不执行，上游没异常
exceptionally 无法捕获运行时未声明的异常？
可以。Java 的异常机制对 CompletableFuture 没有特殊限制，exceptionally 能捕获所有 Throwable 子类，包括 RuntimeException、Error（如 OutOfMemoryError），只要它没被上游提前处理掉。
- 但注意：
Error类异常通常不应靠exceptionally恢复，而是该让进程退出或监控告警 - 常见错误现象：写了
exceptionally却仍看到线程中断或应用崩溃——大概率是Error被传播到了 ForkJoinPool 的默认线程，未被任何 handler 拦截 - 建议做法：对关键链路，优先用
handle+ 显式判空/判异常，比依赖exceptionally更可控
多个 exceptionally 连续写会有叠加效果吗
不会。每个 exceptionally 只作用于它直接修饰的那个阶段，后续再接的 exceptionally 是针对新阶段的，跟前面的无关。
立即学习“Java免费学习笔记（深入）”；
- 典型误解：以为写两次
exceptionally就能“双重兜底”，其实第二个根本不会触发，除非第一个自己又抛了异常 - 示例：
supplyAsync(() -> { throw new RuntimeException("first"); })
.exceptionally(t -> { throw new RuntimeException("second"); }) // 这里抛出新异常
.exceptionally(t -> "final"); // ✅ 这个会捕获 "second"
真正容易被忽略的是：异常一旦被 exceptionally 拦截并返回正常值，整个链就转为“成功态”，后续所有 thenXXX 都按 success 走，不会再进别的 exceptionally。
