Java Lambda不能直接抛受检异常，因需匹配函数式接口无throws声明的抽象方法；常用解法是捕获后包装为RuntimeException并保留cause，或定义带throws的自定义接口、外围预处理异常。
Java 中 Lambda 表达式不能直接抛出受检异常，根本原因在于它必须严格匹配函数式接口的抽象方法签名——而 JDK 内置接口（如 Function、Consumer、Supplier）均未声明 throws 受检异常。这不是语法缺陷，而是类型系统对契约的强制校验。处理的关键不是“绕过语言”，而是用符合 Java 习惯的方式适配约束。
在 Lambda 内捕获并包装为 RuntimeException
这是最常用、零依赖、编译期安全的做法。核心是把受检异常转为非受检异常再抛出，JVM 允许且无需修改方法签名。
- 直接使用
throw new RuntimeException(e)，保留原始异常作为 cause，栈追踪完整 - 避免裸写
throw new RuntimeException("xxx")—— 会丢失原始异常类型和堆栈 - 适合错误需中断流程、且上层不关心具体异常类型的场景，例如流处理中某条记录解析失败即终止
封装通用 rethrow 工具方法
重复写 new RuntimeException(e) 易出错、可读性差。可定义静态工具类统一处理：
- 提供泛型
<E extends Exception> void rethrow(Exception e) throws E方法，利用类型擦除实现“伪检查”抛出 - Lambda 内直接写
Exceptions.rethrow(e)，语义清晰，调用无 try-catch - 比手动 new 更易维护，也便于后续统一添加日志或监控埋点
定义带 throws 声明的自定义函数式接口
当某类操作高频抛出特定受检异常（如 IO、反射、JSON 解析），推荐从契约层面增强类型安全：
- 声明
@FunctionalInterface interface ThrowingFunction<T, R> { R apply(T t) throws Exception; } - 配合包装器（如
Try.of(throwingFunc)）转为标准Function，内部自动捕获并转 RuntimeException - 接口本身显式表达“可能失败”，利于团队理解与 IDE 提示，比隐式包装更可持续
提前在外围处理异常，让 Lambda 保持纯逻辑
并非所有异常都需要在 Lambda 内响应。有时更合理的做法是把易出错操作前置：
- 用工具方法预加载/预校验：例如
String content = safeReadFile("conf.txt")，内部已捕获 IOException 并返回 Optional 或默认值 - 将异常结果建模为数据：用
Optional<T>、Result<T, E>（如 Vavr Try）或自定义容器承载成功/失败状态 - Lambda 仅处理“确定可用”的输入，代码更简洁、测试更直接、错误边界更清晰
