在Project Reactor响应式流操作符中用try catch是否不妥？为何优先选onErrorContinue

场景描述 #

在探索Project Reactor响应式流时，遇到这样的场景：当处理当前事件发生错误（例如反序列化错误）时，需要跳过当前事件，继续处理下一个事件。

针对该场景，存在两种常见处理方式：使用onErrorContinue操作符，或用try catch包裹回调。示例代码如下：

Flux.just(1, 2, 3, 4, 5).mapNotNull(item -> {                                                         
    try {                                                                                             
        System.out.println("item = " + item);                                                         
        if (item.equals(3)) throw new IllegalArgumentException(); // 模拟反序列化错误
        return item;                                                                                  
    } catch (Exception exception){                                                                    
        System.out.println(exception);                                                                
        return null;                                                                                  
    }                                                                                                 
}).subscribe(item -> System.out.println("got element :" + item));

核心问题 #

1. 除了遵循函数式响应式编程风格外，是否还有其他理由优先选择onErrorContinue？
2. 这种try catch的处理方式是否存在问题？

问题解答 #

优先选择onErrorContinue的额外理由 #

• 错误处理与业务逻辑解耦：try-catch会把错误处理代码嵌入业务转换的回调中，导致业务逻辑和错误处理混在一起。onErrorContinue可以将错误处理逻辑抽离为独立的Consumer，专注于错误日志记录、异常统计等操作，让业务代码更简洁清晰。
• 统一处理多操作符错误：如果流中包含多个可能抛出异常的操作符（如map、flatMap、filter），try-catch需要在每个回调中重复编写，而onErrorContinue可以全局或针对特定操作符统一处理错误，避免代码冗余。
• 适配异步场景：对于flatMap这类异步操作，内部抛出的异常无法被当前回调的try-catch捕获（异常发生在异步线程，不会冒泡到当前线程的捕获块），而onErrorContinue能正确捕获流中同步、异步阶段的所有错误，确保跳过错误元素后继续处理后续流。
• 贴合Reactor错误语义与上下文机制：onErrorContinue属于Reactor原生的错误处理操作符，能自然结合Reactor的Context机制传递错误上下文（如请求ID、用户信息等），而传统try-catch无法利用这些响应式特性。

try catch处理方式的潜在问题 #

• 代码冗余与维护成本高：每个可能抛出异常的操作符回调都需要重复编写try-catch块，增加代码量的同时，后续修改错误处理逻辑时需要逐一修改所有回调，维护成本高。
• 异步场景下失效：如前文所述，异步操作中抛出的异常无法被当前回调的try-catch捕获，会直接触发流的onError信号导致整个流终止，无法实现“跳过当前元素继续处理”的需求。
• 语义不明确：通过返回null给mapNotNull来跳过元素，是利用操作符的特性间接实现错误跳过，而非明确的错误处理语义，其他维护者需要额外理解代码意图；而onErrorContinue直接表达了“遇到错误则继续处理下一个元素”的逻辑，可读性更强。
• 无法覆盖操作符内部错误：try-catch只能捕获回调代码中抛出的异常，无法处理操作符自身内部的错误（如某些操作符的实现逻辑异常），而onErrorContinue能处理流生命周期中各个阶段的错误。

内容的提问来源于stack exchange，提问作者younes elmorabit