handle是CompletableFuture中唯一能同时处理正常结果和异常的回调方法，通过BiFunction参数天然互斥实现统一处理：成功时result为实际值（可null）、throwable为null；失败时result为null、throwable为原始异常；必须先判throwable!=null再分支处理，两分支返回相同类型R，典型用于HTTP解析、结果后处理+降级、分类响应异常及日志打点，禁用耗时操作与忽略result空值。
handle 是 CompletableFuture 中唯一能同时拿到正常结果和异常的回调方法，靠参数判空实现真正统一处理——不依赖执行路径，也不隐式吞异常。
handle 的参数逻辑必须先搞清
它接收一个 BiFunction，两个参数天然互斥：
- 任务成功时：
result是实际返回值（可能为null），throwable一定为null - 任务失败时：
result一定为null（不是业务返回的null，而是 handle 明确置空），throwable是原始异常 - 必须先判断
throwable != null再决定走哪条分支，否则容易触发NullPointerException
返回值类型要严格一致
handle 的返回类型 R 会成为新 CompletableFuture 的泛型，所以两分支必须返回相同类型：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 成功分支返回
"ok"，异常分支就得返回"fallback"或""，不能一个返回String、一个返回Integer - 若原始是
CompletableFuture，异常分支别返回- >
"empty"，而应返回Collections.emptyList() - 推荐封装
Result类，成功调用Result.success(data)，异常调用Result.failure(ex)，让返回类型始终是Result
适合 handle 的典型场景
它不是万能兜底，而是为“需要上下文联动”的处理而生：
- HTTP 调用后统一解析：状态码 200 → 解析 JSON；404 → 返回默认用户；500 → 记录告警并降级
- 结果后处理 + 异常降级一起做：比如成功时对字符串 trim 并转大写，失败时返回固定兜底值
- 分类响应不同异常：对
TimeoutException返回缓存，对IOException重试，其他异常原样抛出 - 配合日志打点：无论成败都记录耗时、入参、结果摘要或异常简述，便于链路追踪
别踩这些常见坑
很多问题不是 handle 不好用，而是用法偏了：
- 在
throwable == null分支里直接调用result.toString()—— 忘记result本身可能是null，应先判空 - 异常分支只写
System.out.println，没配日志框架或没 flush，导致异常输出丢失 - 在 handle 里做远程日志上报、数据库写入等耗时操作——它默认在前一阶段线程中同步执行，会拖慢整个异步流
- 误以为 handle 会吞异常：其实它不拦截也不压制，你在里面
throw new RuntimeException()，下游照样收到CompletionException
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
