java stream 默认遇异常中断处理，解决方法是：在lambda内捕获异常返回默认值（如null）并配合filter过滤，或封装为工具方法（如safeparseint）提升可读性；对受检异常可用checkedfunction包装；需记录错误时用either或result封装结果后collect分流。
Java Stream 中遇到异常，默认会中断整个流处理，后续元素不再执行。这不是 bug，而是设计使然——Stream 强调函数式、无状态、短路语义。但实际业务中，我们往往需要“错的归错的，对的继续跑”。解决核心就两条路：一是不让异常逃出 lambda，二是把异常转化成数据的一部分。
在 lambda 内部捕获并消化异常
适用于运行时异常（如 NumberFormatException）或你愿意主动包装的受检异常。关键不是“不抛”，而是“不让流感知到它”。
- 用 try-catch 捕获后返回默认值（如 null、Optional.empty()、空对象），再配合 filter 或 map 过滤/转换
- 避免在 catch 块里直接 throw new RuntimeException(e)，除非你真想中止流；否则这和没处理一样
- 示例：解析字符串为整数，跳过非法项
.map(s -> {
try { return Integer.parseInt(s); }
catch (NumberFormatException e) { return null; }
})
.filter(Objects::nonNull)
.reduce(0, Integer::sum);
把异常逻辑抽离成独立方法
让 lambda 保持简洁，把 try-catch 封装进普通方法里，再通过方法引用调用。可读性、复用性、测试性都更好。
- 定义一个私有工具方法，比如 safeParseInt(String s)，内部处理异常并返回 Optional 或默认值
- 在 stream 中使用 .map(this::safeParseInt)，清晰表达意图
- 若需区分成功/失败结果，可返回自定义容器（如 Either
）
用包装器统一处理受检异常
Java 不允许 lambda 直接抛出受检异常（如 IOException）。通用解法是定义一个 CheckedFunction 接口 + 静态包装方法，把受检异常转为 RuntimeException，但只在必要时抛出。
立即学习“Java免费学习笔记（深入）”；
- 包装器不吞异常，只是“绕过编译检查”，真正异常仍可被捕获或记录
- 适合 I/O 类操作（如读 URL、解析 XML），失败时通常需告警而非静默跳过
- 注意：不要滥用 —— 若多数输入都会失败，说明数据质量或接口设计有问题，该前置校验
收集异常与正常结果分离处理
当既要完成有效数据的处理，又要完整记录所有错误时，推荐用 Either 或自定义结果类（如 Result
