CompletableFuture不支持直接抛出受检异常，因其函数式接口方法签名未声明throws；必须用try-catch包装为RuntimeException或其子类，才能被exceptionally捕获并保留cause。
CompletableFuture 本身不支持直接抛出受检异常（Exception 及其非 RuntimeException 子类），因为它的异步函数式接口（如 Supplier、Function、Consumer）在方法签名中**没有声明抛出受检异常**。编译器会拒绝你在 supplyAsync 或 thenApply 的 lambda 中直接 throw new IOException() 这类写法。
为什么受检异常不能直接抛出
Java 的函数式接口设计是“契约式”的：
– Supplier 的 get() 方法签名是 T get()，没声明 throws Exception
– 所以 lambda 体内若出现受检异常，必须被显式处理（捕获或包装），否则编译失败
– 这不是 CompletableFuture 的限制，而是 Java 类型系统对函数式接口的硬性要求
正确处理方式：主动包装为非受检异常
业务逻辑中若涉及可能抛出受检异常的操作（如文件读取、网络请求、JDBC 调用），需在 lambda 内部用 try-catch 将其转为 RuntimeException 或其子类：
- 推荐使用
RuntimeException包装，保留原始异常作为 cause：
try {
return Files.readString(Paths.get("config.txt"));
} catch (IOException e) {
throw new RuntimeException("读取配置失败", e); // ✅ 包装后可被 exceptionally 捕获
}
}).exceptionally(ex -> {
System.err.println("降级处理：" + ex.getCause()); // 可拿到原始 IOException
return "default-config";
});
- 也可自定义运行时异常类型（如
IoRuntimeException），便于下游按类型区分处理 - 切勿用空 catch 吞掉受检异常——这会导致问题静默，违背容错设计初衷
exceptionally 能捕获包装后的受检异常吗
可以，但要注意：
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
-
exceptionally接收的是Throwable，它能捕获所有非受检异常，包括你手动包装的RuntimeException - 原始受检异常已作为 cause 存在于该
RuntimeException中，调用ex.getCause()即可还原 - 如果未做包装，代码根本无法通过编译，也就不存在“能否捕获”的问题
替代方案：用 handle 统一兜底更安全
若想避免在每个 supplyAsync 里重复写 try-catch，可将受检操作封装成工具方法，并统一用 handle 处理结果与异常：
.handle((result, ex) -> {
if (ex != null) {
Throwable cause = ex.getCause();
if (cause instanceof IOException) {
log.warn("配置读取异常，启用默认值", cause);
return "default";
}
throw new CompletionException(cause); // 重新抛出供上游处理
}
return result;
});
这种方式把异常判断和恢复逻辑集中，也便于统一日志和监控。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
