Java 8 Lambda里直接throw异常会编译失败
因为标准函数式接口（如 Function、Consumer、Supplier）的抽象方法**不声明受检异常**（checked exception），而Lambda体里若出现 IOException、SQLException 这类，编译器就报错：Unhandled exception type XXXException。
这不是Lambda的bug，是函数式接口设计时就规避了异常声明——它面向的是“纯计算”，不是I/O或数据库这类易出错场景。
- 别试图在Lambda里裸写
throw new IOException()，一定过不了编译 - 也不要改写成
try-catch吞掉异常再返回null或默认值，这会让调用方完全感知不到失败 - 更别用
throws Exception去强行加在Lambda参数类型上——接口方法签名固定，改不了
用自定义函数式接口包装受检异常
核心思路：自己定义一个类似 Function 但允许抛异常的接口，比如叫 ThrowingFunction，再配一个静态工具方法把它“转回”标准接口。
示例：
立即学习“Java免费学习笔记（深入）”；
@FunctionalInterface
public interface ThrowingFunction<T, R> {
R apply(T t) throws Exception;
}
public class LambdaUtil {
public static <T, R> Function<T, R> unchecked(ThrowingFunction<T, R> f) {
return t -> {
try {
return f.apply(t);
} catch (Exception e) {
throw new RuntimeException(e);
}
};
}
}
- 接口本身不解决异常传播问题，只是让Lambda体能合法写
throw -
unchecked()是关键桥接：把受检异常转为RuntimeException，绕过编译检查 - 注意运行时异常类型是
RuntimeException包裹的，原始异常在getCause()里
Stream.forEach里处理IO异常的典型踩坑点
常见需求：遍历文件列表并读取内容，用 files.stream().forEach(path -> Files.readString(path)) ——这行不通，Files.readString() 抛 IOException。
- 错误做法：写成
forEach(path -> { try { ... } catch (IOException e) { ... } })，异常被吞，后续逻辑可能拿空值继续跑 - 正确路径：先用
ThrowingFunction+unchecked()转换，再进forEach，确保异常至少能打断执行或被外层捕获 - 更稳妥的做法其实是不用
forEach，改用map(unchecked(...)).collect(...)，让异常在收集阶段统一暴露 - 别忘了：
Stream的短路操作（如findFirst）遇到异常会中断，但forEach不保证顺序和中断行为，异常发生后流可能已部分消费
为什么不用CheckedFunction等第三方库？
像 vavr 或 functional-java 确实提供了带异常的函数接口，但引入它们往往带来额外复杂度。
- 版本冲突风险：这些库的
Function和 JDK 的同名类不兼容，混用会导致泛型擦除或编译错误 - 调试成本高：异常栈里夹杂多层包装类，原始
IOException被埋得更深 - 团队认知负担：新成员要同时理解JDK原生函数式接口 + 第三方扩展，不如手写一个5行
ThrowingFunction来得直白 - 真正需要的是控制权——你要决定异常是转成
RuntimeException、封装成Optional，还是走回调通知，这些都该由业务代码显式表达，而不是依赖库的默认策略
异常包装不是加一层try-catch就完事，关键是让异常路径可预测、可追溯、不静默失效。最常被忽略的，是忘记检查 RuntimeException 的 getCause()，结果日志里只看到“java.lang.RuntimeException”，根本看不出底层到底是文件没找到还是磁盘满。
