Java Stream API不支持直接抛出Checked Exception，需将其转为Unchecked Exception；常用方法包括lambda内try-catch包装、封装CheckedFunction接口工具类，以及按业务选择尽最大努力、立即中断或收集异常策略。
Java Stream API 本身不支持直接抛出或传播 Checked Exception，因为其函数式接口（如 Function、Consumer、Supplier）没有 throws 声明。一旦你在 lambda 中调用可能抛出 Checked Exception 的方法，编译器就会报错：unreported exception XXX; must be caught or declared to be thrown。核心解法不是绕开异常，而是把 Checked Exception 转为 Unchecked Exception，让流能继续执行。
在 Lambda 内部 try-catch 并包装为 RuntimeException
这是最直接、无需额外依赖的方式。适用于单次操作或逻辑较轻的场景。
- 对每个可能抛异常的操作加一层
try-catch - 捕获后用
new RuntimeException(e)包装并抛出 - 注意保留原始异常栈信息，推荐使用
new RuntimeException(e)而非new RuntimeException(e.getMessage())
示例：
list.stream().map(item -> {
try {
return Files.readString(Paths.get(item)); // 可能抛 IOException
} catch (IOException e) {
throw new RuntimeException(e);
}
})
.forEach(System.out::println);
封装通用的异常包装工具方法
避免重复写 try-catch，提升可读性和复用性。适合中大型项目或多处需处理 Checked Exception 的场景。
立即学习“Java免费学习笔记（深入）”；
- 定义一个自定义函数式接口，允许声明
throws Exception - 提供静态包装方法，将该接口转为标准
Function等 - 所有业务逻辑集中在接口实现里，异常处理由工具统一收口
示例接口与工具类：
public interface CheckedFunction<T, R> {R apply(T t) throws Exception;
}
public static <T, R> Function<T, R> wrap(CheckedFunction<T, R> f) {
return t -> {
try { return f.apply(t); }
catch (Exception e) { throw new RuntimeException(e); }
};
}
按业务语义选择失败策略：尽最大努力 vs 立即中断
不是所有异常都要“吞掉”。要结合实际需求决定流的容错行为。
-
尽最大努力（Best Effort）：个别元素失败不影响整体，用
Optional包装结果再过滤 -
立即失败（Fail Fast）：任一元素出错就终止整个流，靠包装后的
RuntimeException自然传播 -
收集异常（Collect Errors）：需要诊断问题时，可改用
Stream.collect()累积成功结果和异常列表
例如尽最大努力加载用户：
userIds.stream().map(id -> {
try { return Optional.of(userService.load(id)); }
catch (UserLoadException e) { return Optional.empty(); }
})
.filter(Optional::isPresent)
.map(Optional::get)
.collect(Collectors.toList());
递归扁平化等复杂场景的特别提醒
像递归处理嵌套数组、树形结构时，若扁平化方法本身声明了 throws Exception，Stream 的 flatMap 就无法直接引用它。
- 优先移除递归方法签名中的
throws Exception—— 大多数纯数据转换逻辑本就不该抛 Checked Exception - 若底层确实有 I/O 或反射调用，应在递归方法内部捕获并转为
RuntimeException - 避免在流中间操作中做耗时或不可控的异常恢复，保持流的声明式语义
不复杂但容易忽略。
