exceptionally() 捕获当前阶段或其直接上游链路中未被处理的异常，接收原始Throwable实例并返回同类型替代值，实现失败态到成功态的转换。

CompletableFuture 的 exceptionally() 不捕获异常变量本身，而是接收上游抛出的 Throwable 实例，并用它计算出一个**替代结果值**，从而把“失败态”转为“成功态”。它不是异常处理器，而是异常恢复器。

exceptionally() 捕获什么？

它只响应当前 CompletableFuture 所在阶段或其**直接上游链路中任意一个未被处理的异常**。注意三点：

• 异常必须是未被前面的 handle 或 exceptionally 吞掉的；一旦被前序 exceptionally 返回了值，后续就再不会触发
• 它接收的是原始异常对象（比如 RuntimeException 或 ExecutionException 包裹的 cause），不是“异常变量名”——Java 中没有运行时异常变量的概念
• 若上游是 supplyAsync 抛出 NullPointerException，exceptionally 参数就是那个 NPE 实例，可直接 instanceof 判断或调用 getCause()

exceptionally() 怎么转换异常？

它不转换异常类型，也不重抛异常，而是绕过异常、返回新值。所谓“转换”，实质是业务逻辑映射：

• 返回默认字符串、空集合、兜底 DTO，让下游能继续 thenApply 或 join
• 可内部做日志、监控上报，但这些是副作用，不影响返回值语义
• 不能改变泛型类型：如果原 CompletableFuture，exceptionally 的 lambda 必须返回 String，不能返回 Integer 或 void

常见误用与陷阱

很多问题源于对“捕获后是否还存在异常”的误解：

• 在 exceptionally 里 throw new RuntimeException(...) —— 这会让异常重新抛出，下游再次失败，失去兜底意义
• 以为它能区分是哪个子任务出错 —— 实际上它只知道“链上炸了”，不知道是 thenCompose 还是 supplyAsync 出的问题
• 和 handle() 混用导致逻辑重复：比如先写 handle 做分类处理，又加 exceptionally，后者根本不会执行

什么时候该用 exceptionally()？

适合明确需要“失败即降级”的场景，且降级结果与原类型一致：

• 远程调用超时，返回缓存数据
• 数据库查询异常，返回空列表
• 图片生成失败，返回占位图 URL 字符串
• 不适用于需重试、需转换异常为 Checked Exception、或需中断流程的校验类错误