Java Lambda不能直接抛受检异常，需通过转为运行时异常、定义支持throws的自定义函数式接口、用Try/Optional建模异常或移出Lambda外围处理四种方式解决。
Java 的 Lambda 表达式本身不能直接抛出受检异常（checked exception），因为 JDK 内置的函数式接口（如 Function、Consumer）方法签名中没有 throws 子句。编译器会拒绝这种写法。真正可行的做法不是硬塞 try-catch 进去破坏可读性，而是根据场景选择更清晰、可维护的异常处理路径。
在 Lambda 内用 try-catch 包装并转为运行时异常
这是最常用、无需额外依赖的方式。关键不是“吞掉异常”，而是保留原始堆栈和类型信息，再以非受检形式抛出。
- 用
throw new RuntimeException(e)，确保传入原始异常作为 cause，避免丢失上下文 - 优先选用语义明确的子类，比如
UncheckedIOException（对应IOException）、CompletionException（配合CompletableFuture） - 避免裸写
throw new RuntimeException("xxx")—— 这会切断异常链，调试困难
定义支持 throws 的自定义函数式接口
当某类操作（如文件读取、JSON 解析、数据库查询）频繁出现在流式处理中，推荐从契约层面增强表达力。
- 声明
@FunctionalInterface interface ThrowingFunction<T, R> { R apply(T t) throws Exception; } - 配套提供静态工具方法，例如
ThrowingFunction.uncheck()，内部做 try-catch 并返回标准Function<T, R> - 调用端仍保持
.map(...)风格，但接口本身显式传达“此处可能失败”，利于协作与 IDE 提示
用 Try 或 Optional 把异常建模为数据
把“失败”当作一种合法状态来处理，而不是流程中断点。适合需要容错、降级或聚合错误结果的场景。
立即学习“Java免费学习笔记（深入）”；
- Vavr 的
Try<T>可封装可能抛异常的计算，支持map、recover、getOrElse等链式操作 - 用
Optional<T>表示“可能不存在”，配合预校验（如Files.exists()）提前规避IOException - 自定义
Result<T, E>类型（类似 Rust 的 Result）也能让错误路径一目了然
把易错操作移出 Lambda，外围统一处理
不是所有异常都该在 Lambda 里响应。有时最优雅的解法是让 Lambda 只处理“确定成功”的输入。
- 封装工具方法，如
safeReadFile(path)，内部捕获IOException并返回Optional<String>或默认内容 - 对集合做预过滤：先用
filter(Files::exists)或filter(s -> !s.isBlank())排除明显非法项 - 流式处理前统一加载、校验、转换，Lambda 仅专注纯业务逻辑，测试也更简单
