Lambda表达式不能直接抛出受检异常，因函数式接口方法未声明throws；需自定义ThrowingFunction接口并配unchecked包装器，将受检异常转为RuntimeException且保留cause链。
Lambda里抛出受检异常会编译失败
Java的Lambda表达式本身不支持直接抛出Exception或任何受检异常（checked exception），因为函数式接口（如Consumer、Function）的抽象方法签名里没声明throws Exception。你写list.forEach(x -> readFile(x))，而readFile抛IOException，编译器立刻报错：Unhandled exception: java.io.IOException。
这不是Lambda“不行”，而是类型系统卡在契约上——接口没说能抛，你就不能抛。
- 常见错误现象：
Unresolved compilation problem: Unhandled exception type XXXException - 别用
try-catch包一层再吞掉异常，那会让调用方完全失察 - 也不建议把所有异常都转成
RuntimeException往上扔，丢失原始类型信息和栈追踪上下文 - 真正可控的做法：定义一个带
throws能力的函数式接口，并配套包装器
自定义ThrowingFunction接口要匹配JDK常用签名
你不需要重 invent the wheel，但得让新接口和Function、Consumer等保持行为一致，否则后续组合（比如.andThen()）会断掉。重点是泛型参数、返回值、入参个数，以及——必须保留throws E extends Throwable声明。
例如这个最常用的：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
@FunctionalInterface
public interface ThrowingFunction<T, R, E extends Throwable> {
R apply(T t) throws E;
}
- 不要加多余方法（比如
compose()），除非你真需要且已实现 - 泛型
E必须是Throwable子类，否则无法捕获具体异常类型 - 如果只处理
IOException，别写死throws IOException，限制太死；留泛型更灵活 - 注意：JDK 8 没提供这类接口，所以必须自己定义；JDK 19+ 的
java.util.function仍无原生支持
包装器方法要用Unchecked前缀并明确异常转化逻辑
有了接口，还得让老代码能无缝接入。典型做法是写一个静态工具方法，把ThrowingFunction转成普通Function，但关键是怎么转——不是简单套new RuntimeException(e)。
推荐命名如unchecked()或uncheck()，语义清晰：
public static <T, R> Function<T, R> unchecked(ThrowingFunction<T, R, ? extends Throwable> f) {
return t -> {
try {
return f.apply(t);
} catch (Throwable e) {
throw new RuntimeException(e); // 包装但不丢原始cause
}
};
}
- 必须用
throw new RuntimeException(e)，而不是throw new RuntimeException(e.getMessage())，否则丢失堆栈 - 别在catch里
printStackTrace()，那是调试行为，不是包装器职责 - 如果业务强依赖原始异常类型（比如要区分
SQLException和TimeoutException），就别用通用包装器，改用专门的SQLExceptionFunction等 - 性能影响极小：只有异常发生时才多一次包装，正常路径零开销
实际用法中容易漏掉异常恢复点
包装器解决的是“编译通过”问题，但不等于“错误被处理”。很多人写了unchecked()就以为万事大吉，结果运行时异常一冒，整个stream中断，或者回调静默失败。
真实场景里，你要决定异常在哪一层兜住：
- 如果是批量处理（如
list.parallelStream().map(unchecked(this::parseJson))），得考虑是否允许单条失败不影响整体——这时应在parseJson内部做局部恢复，而不是靠外层包装 - 如果用在Spring WebFlux的
Mono.map()里，包装后的RuntimeException会被转成OnErrorNotImplementedException，反而掩盖根源 - 日志记录点容易错位：在包装器里log，会重复打；在原始方法里log，又可能被吞；建议只在最终消费处（如controller、service入口）统一捕获+log
- 单元测试时，别只测“能跑通”，一定要用
assertThrows验证原始异常是否被正确包装并保留cause链
兼容性从来不在语法层面，而在异常生命周期的每个落点是否有人盯着。Lambda只是触发器，真正的复杂度藏在你决定让哪个环节知道、什么时候知道、以什么形式知道那个异常。
