CompletableFuture异常处理：exceptionally与handle用法解析

exceptionally仅捕获上游异常且必须返回同类型结果；handle则统一处理成功与异常两种情况，参数为BiFunction，支持结果清洗与日志聚合。

exceptionally 只捕获上游异常，且必须返回同类型结果

当你只关心“出错了怎么兜底”，不打算处理正常流程，exceptionally 是最轻量的选择。但它有个硬约束：参数只能是 Throwable，返回值类型必须和原始 CompletableFuture 的泛型一致——哪怕你只是想返回个默认值，也得手动 cast 或构造。

• 常见错误现象：exceptionally 里 return null 导致下游 join() 报 NullPointerException（尤其泛型是基本类型包装类时）
• 使用场景：HTTP 调用失败时返回缓存值、降级响应，或统一打点后抛运行时异常
• 参数差异：它不接收正常结果，所以拿不到成功时的 String、Integer 等值，纯异常通道
• 示例：future.exceptionally(t -> { log.error("fetch failed", t); return "default"; })

handle 是真正的“结果/异常二合一”处理器

handle 的签名是 BiFunction，两个参数始终存在：成功时 Throwable 为 null，失败时 T 为 null。这意味着你能写统一逻辑判断分支，也更容易做类型转换或日志聚合。

• 常见错误现象：误以为 handle 中的 Throwable 非空就代表“一定失败”，其实上游可能主动返回了 null 结果 + null 异常（极少见但合法）
• 使用场景：需要根据成功/失败分别记录不同指标、做结果清洗（如把异常转成特定错误码）、或统一包装成 Result<T> 类型
• 性能影响：比 exceptionally 多一次函数调用开销，但几乎可忽略；关键是它强制你面对两种路径，不易漏判
• 示例：future.handle((result, ex) -> ex != null ? "fallback" : result.toUpperCase())

别在 exceptionally 里 throw 新异常，除非你真想中断链式调用

exceptionally 的设计本意是“兜底并继续”，如果你在里面 throw 新异常，下游的 thenApply 会跳过，但再后面的 exceptionally 或 handle 仍能捕获——这容易造成异常处理逻辑分散，调试时找不到源头。

• 容易踩的坑：用 exceptionally 做日志 + rethrow，结果发现异常没被上层 try/catch 捕获，因为 CompletableFuture 默认异步执行，异常会“掉进黑洞”
• 正确做法：想中断就用 handle 显式返回 null 或特殊标记，再由下游判断；真要抛异常，优先用 whenComplete（它不改变结果类型，只做副作用）
• 兼容性注意：Java 8 的 exceptionally 无法处理 CompletionException 包裹的原始异常，需用 getCause() 解包才能匹配业务异常类型

handle 和 exceptionally 对下游链的影响完全一致

很多人以为 handle 会“吞掉”异常、让后续 thenApply 正常执行，其实不然：只要 handle 返回的是非异常结果，下游就收到该结果；如果 handle 自己抛了异常，或者返回 null（而泛型不可为空），下游照样走异常路径。这点和 exceptionally 行为对齐，但容易因命名产生误解。

• 关键细节：两者都**不会改变 CompletableFuture 的完成状态**——失败就是失败，成功就是成功，只是替换了结果值
• 调试建议：加 whenComplete((r, e) -> System.out.println(r + "/" + e)) 在链尾，一眼看清最终交付的是什么
• 真实陷阱：当上游是 supplyAsync(() -> { throw new RuntimeException(); })，handle 的 ex 参数是 CompletionException，不是原始 RuntimeException，直接 instanceof 会失败