exceptionally是completablefuture中专用于异常恢复的回调方法，仅在前序阶段抛出未检查异常时触发，返回类型匹配的兜底值以维持链式调用；它不处理受检异常、不传播原异常、不执行副作用，仅提供降级响应。
exceptionally 是 CompletableFuture 中专用于异常恢复的回调方法，它不中断链式调用，只在前序阶段抛出未检查异常（RuntimeException 或其子类）时触发，返回一个兜底值来“接住”失败，让后续操作（如 thenApply、thenAccept）仍能正常执行。
它只响应运行时异常，对受检异常无效
因为 supplyAsync、thenApply 等方法接收的函数接口（如 Supplier<t></t>、Function<t></t>）不声明抛出受检异常，编译器不允许直接 throw Exception。若业务逻辑中必须处理受检异常，需主动包装：
- 用
try-catch捕获后转为RuntimeException，例如throw new RuntimeException(e) - 更推荐使用
CompletionException包装，这是 CompletableFuture 内部标准做法，保留原始异常栈信息
它的参数和返回值必须类型一致
exceptionally 接收一个 Function<throwable t></throwable>，其中 T 必须与前序阶段的完成结果类型完全相同。比如前一步是 CompletableFuture<string></string>，那 exceptionally 就必须返回 String，不能返回 Object 或 null（除非 T 本身是 String 类型且允许 null）。
常见错误是返回类型不匹配，导致编译失败或运行时 ClassCastException。
它不处理异常传播，只提供替代结果
与 handle 不同，exceptionally 的函数体内只拿到 Throwable，拿不到正常结果；它也不感知成功路径，不执行日志、清理或通知等副作用。它的唯一职责是：异常发生时，给出一个合法的、类型兼容的默认值。
- 适合场景：远程调用失败返回缓存值、空列表、默认文案等“降级响应”
- 不适合场景：需要重试、记录详细上下文、区分异常类型做不同处理、释放资源
它不会吞掉异常，但也不会暴露给下游
调用 exceptionally 后，原异常被“覆盖”，新 CompletableFuture 会以你返回的兜底值正常完成。这意味着：
- 下游的
thenAccept或join()拿到的是兜底值，不是异常 - 如果想让异常继续向后传递（比如交给全局异常处理器），就不能用
exceptionally，而应选handle并在其中重新抛出，或用whenComplete做记录后不干预结果
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
