Lambda表达式不能直接抛出受检异常，因标准函数式接口方法未声明throws；外层try-catch无法捕获forEach中异常，因其作用域限于Lambda内部；应通过自定义ThrowingFunction或unchecked包装器处理，或改用map/collect等可中断、可集中捕获异常的流操作。
Java 中 Lambda 表达式本身不能直接抛出受检异常（checked exception），这是由函数式接口的设计决定的——标准接口如 Function、Consumer、Supplier 的抽象方法不声明 throws，所以你在 Lambda 体里写 throw new IOException() 会编译失败。
为什么外层 try-catch 捕获不到 forEach 里的异常
这是因为 forEach 是一个高阶方法，它把 Lambda 当作回调执行。异常发生在 Lambda 内部，而该 Lambda 的调用栈不在你的外层代码块中，所以外层的 try-catch 根本“看不见”它。这不是 bug，是 Java 异常作用域机制的自然结果。
- 异常只能被**直接包裹它所在代码块**的
try-catch捕获 -
iterable.forEach(item -> { throw new IOException(); })中的异常，作用域仅限于这个 Lambda 表达式内部 - 即使你在外层写了
try { iterable.forEach(...) } catch (Exception e) { }，也捕获不到
处理受检异常的常用方式
核心思路不是“绕过异常检查”，而是让异常能合法出现在 Lambda 体中，并以可控方式暴露出来。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 定义自己的函数式接口，比如
ThrowingFunction<T, R>，其apply方法声明throws Exception - 提供一个工具方法（如
unchecked()），把ThrowingFunction转成标准Function：内部用try-catch把受检异常包装为RuntimeException抛出 - 这样既通过了编译，又没吞掉异常——原始异常仍可通过
e.getCause()获取
更稳妥的数据流异常处理策略
比起在 forEach 里硬塞异常逻辑，推荐改用 map().collect() 这类终端操作：
立即学习“Java免费学习笔记（深入）”；
stream.map(unchecked(path -> Files.readString(path))).collect(Collectors.toList())- 异常会在收集阶段集中暴露，调用方能统一感知和处理
- 避免
forEach的不确定性：它不保证执行顺序，也不保证遇到异常就中断；而map + collect在中间出错时会自然终止并抛异常
哪些做法要避免
这些看似能“跑通”的写法，实际埋下隐患：
- 在 Lambda 里
try-catch吞掉异常，然后返回null或默认值——调用方无法区分“成功返回 null”和“出错后被迫返回 null” - 强行给 Lambda 参数类型加
throws——函数式接口方法签名是固定的，改不了 - 依赖第三方库（如 Vavr 的
CheckedFunction）引入额外复杂度，尤其在轻量项目中得不偿失
