Java中lambda不能直接抛受检异常，因其必须匹配函数式接口方法签名，而JDK内置接口均未声明throws；可捕获处理、包装为RuntimeException或定义带throws的自定义接口解决。
Java中的lambda表达式本身不能直接抛出受检异常（checked exception），因为函数式接口的抽象方法通常不声明 throws 子句（如 Runnable.run()、Consumer.accept() 等均无 throws）。若在lambda中抛出受检异常，编译会报错。这是由函数式接口契约决定的，而非lambda语法本身的限制。
为什么lambda不能直接抛受检异常
lambda表达式本质上是函数式接口实例的简写，其行为必须严格匹配接口中抽象方法的签名。而JDK内置的大多数函数式接口（如 Function、Predicate、Supplier）的抽象方法均未声明抛出任何受检异常。因此，当你在lambda里写 throw new IOException();，编译器发现目标方法签名不支持该异常，就会拒绝编译。
- 受检异常必须被显式捕获或在方法签名中声明
- lambda没有独立的方法签名，它“继承”自函数式接口方法的签名
- 运行时异常（unchecked，如
RuntimeException及其子类）不受此限，可直接抛出
绕过限制的常用方式
有几种实用且符合Java习惯的解决路径：
- 在lambda内部捕获并处理受检异常：适合错误可本地消化的场景，例如记录日志后返回默认值
-
将受检异常包装为非受检异常（如 RuntimeException）再抛出：简洁但需注意异常信息完整性，推荐使用
new RuntimeException(e)或自定义运行时异常类 -
定义自己的函数式接口，声明 throws 子句：最规范的方式，适用于高频、跨模块使用的带异常操作，例如：
interface ThrowingConsumer{ void accept(T t) throws Exception; }
配合静态工具方法（如catching(ThrowingConsumer)）可兼顾类型安全与调用简洁性
实际示例对比
假设要遍历文件列表并读取内容（Files.readString 抛出 IOException）：
- ❌ 错误写法（编译失败）：
list.forEach(path -> Files.readString(path)); - ✅ 推荐写法（包装为 RuntimeException）：
list.forEach(path -> { try { System.out.println(Files.readString(path)); } catch (IOException e) { throw new RuntimeException(e); } }); - ✅ 更优雅写法（自定义接口 + 工具方法）：
定义
ThrowingConsumer，再通过工具类转为普通Consumer，一行调用即可保留原始异常语义
注意事项与建议
不要为了“用lambda”而强行忽略异常处理逻辑。是否包装、捕获或重构接口，应取决于异常的业务意义：
- I/O、网络等外部依赖失败，通常值得传播或重试，建议用自定义带throws接口
- 配置缺失、解析失败等可预期错误，可考虑统一转为特定运行时异常（如
ConfigurationException），便于上层分类处理 - 避免裸写
throw new RuntimeException(e)而丢失堆栈——应使用new RuntimeException("read failed", e) - Lombok 的
@SneakyThrows可简化语法，但会隐式吞掉受检异常声明，团队需达成一致并理解其原理
