handle能统一处理成功和异常，因其无论正常或异常完成均被调用，通过BiFunction接收result（异常时为null）和ex（成功时为null），天然支持空值分支判断；区别于exceptionally仅异常触发且强制同类型返回，handle可同时做结果后处理与异常分类响应，且不自动吞异常。
handle 方法为什么能统一处理成功和异常
handle 是少数几个无论 CompletableFuture 正常完成还是异常完成都会被调用的回调方法。它接收两个参数：BiFunction<t throwable r></t>，其中第一个是正常结果（失败时为 null），第二个是异常（成功时为 null）。这种“二选一”的设计天然适合做统一入口：你不需要提前判断链路是否出错，只要在 lambda 里做空值分支即可。
handle 和 exceptionally 的关键区别在哪
二者都可用于异常兜底，但行为差异直接影响代码健壮性：
-
exceptionally只在异常时触发，且必须返回与原始泛型类型一致的值（比如CompletableFuture<string></string>的exceptionally必须返回String） -
handle总是触发，可对成功结果做后处理（如 trim、转换格式），也可对异常做分类响应（如NullPointerException返回默认值，IOException重抛） -
handle不会自动“吞掉”异常——如果你在异常分支里不返回值或抛出新异常，后续thenApply等阶段仍可能因null结果或未捕获异常而中断
实际写法中容易忽略的三个细节
很多开发者写了 handle 却发现日志没打、降级没生效、下游仍报 NullPointerException，问题往往出在这几处：
- 忘记检查
result == null就直接调用其方法，导致二次NullPointerException；正确做法是先判空再操作 - 在
handle的异常分支里用了System.out.println但没加flush或没配日志框架，异常输出被缓冲甚至丢失 - 返回值类型不匹配：比如原始 future 是
CompletableFuture<list>></list>，但在handle里异常分支返回了Arrays.asList("fallback")（类型对），但成功分支却返回了"raw-string"（类型错），编译不过
示例（修正版）：
CompletableFuture<List<String>> future = CompletableFuture
.supplyAsync(() -> {
if (Math.random() > 0.5) throw new NullPointerException("上游空指针");
return Arrays.asList("a", "b");
})
.handle((result, ex) -> {
if (ex != null) {
System.err.println("捕获到异常: " + ex.getClass().getSimpleName());
return Collections.emptyList(); // ✅ 类型一致
}
return result != null ? result.stream().map(String::toUpperCase).collect(Collectors.toList()) : Collections.emptyList();
});
什么时候该用 handle 而不是 whenComplete
whenComplete 看似类似，但它签名是 BiConsumer<t throwable></t>，**不返回值**，只适合副作用操作（如记录耗时、关闭资源）。如果你需要把处理后的结果继续往下传（比如日志+降级后交给 thenAccept 打印），就必须用 handle。
一个典型误用场景：在 whenComplete 里尝试修改 result 字段——没用，因为它的返回值被丢弃，下游拿到的仍是原始异常状态或未处理结果。
复杂点在于：handle 的逻辑一旦出错（比如自己抛了未捕获异常），这个新异常会成为 future 的最终异常状态，且无法被同一级的其他 handle 捕获——它只会向上传递，直到遇到下一个 handle 或调用 .join() 抛出 CompletionException。
