Java函数式接口不支持直接抛出受检异常，需自定义带throws声明的接口（如ThrowingConsumer），再通过适配器转为标准接口并包装为语义明确的运行时异常。
Java 函数式接口本身不支持直接抛出受检异常（checked exception），因为 JDK 内置的接口如 Function、Consumer、Supplier 等，其抽象方法签名中均未声明 throws 子句。编译器会强制拒绝在 Lambda 中抛出 IOException、SQLException 这类受检异常——哪怕只有一行代码，也会报错。
自定义可抛异常的函数式接口
核心思路是绕过标准接口限制，自己定义带 throws 的函数式接口：
- 用
@FunctionalInterface标注，确保只有一个抽象方法 - 在方法签名中明确声明要抛出的异常类型，例如
E extends Exception - 常见命名如
ThrowingSupplier、CheckedFunction、ThrowingConsumer - 示例：
@FunctionalInterface<br>interface ThrowingConsumer<t> {<br> void accept(T t) throws IOException;<br>}</t>
桥接到标准接口需适配异常
自定义接口解决了 Lambda 编写问题，但无法直接用于 Stream 或集合操作。必须通过静态适配器方法转成标准接口：
- 适配逻辑必须显式捕获并处理异常，不能忽略
- 推荐包装为特定运行时异常，如
UncheckedIOException，保留原始异常类型和堆栈 - 避免直接用
new RuntimeException(e)，它会丢失语义，不利于日志分类和全局异常处理器识别 - 若业务允许静默失败，可在适配器中返回默认值或
Optional.empty()
按场景选择封装策略
不是所有异常都该统一包装成运行时异常：
- 逻辑上不可能发生的受检异常（如
new String(bytes, "UTF-8")抛UnsupportedEncodingException），可用@SneakyThrows省略处理 - 第三方 SDK 接口大量抛受检异常，适合封装为
CheckedFunction+ 适配器链，保持调用简洁 - 异步场景（如
CompletableFuture.supplyAsync）中，受检异常必须先转为运行时异常，否则无法提交任务 - 纯校验逻辑可结合
Predicate和自定义抛异常接口，替代if (x == null) throw new XxxException()
关键不在“能不能抛”，而在于让异常流经清晰、类型安全、语义明确的路径。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
