响应式编程中断流水线：抛异常还是传递错误对象更符合规范？

两种方案的规范度对比 #

首先明确结论：第一种返回dummy Mono的方案相对更符合响应式开发规范，两种方案的差异如下：

第二种抛RuntimeException方案的问题 #

• 违反响应式流的错误传递约定：响应式流中所有错误都应该通过Publisher的error信号向下传递，直接在运算符内部抛出JVM级别的未检查异常，会脱离响应式上下文管理，不利于后续的链路追踪、错误分类处理，虽然Spring WebFlux会兜底将其转换为响应式错误信号，但这种写法属于不规范的野路子。
• 错误边界模糊：将业务校验不通过的正常业务错误，和系统运行异常（如WebClient调用超时、空指针、服务不可用等）混为一谈，后续做监控告警、日志排查时，无法快速区分是正常业务逻辑拒绝，还是真的出现了系统故障。
• 全局异常处理器的职责溢出：@ExceptionHandler更适合处理全局的、未被业务逻辑捕获的系统异常，不应该承载业务校验错误的处理逻辑，否则会导致全局异常处理器越来越臃肿，不同业务的错误处理逻辑耦合在一起。

第一种返回dummy Mono方案的优劣 #

• 优势：全程通过响应式流的正常信号传递数据，没有破坏响应式上下文，业务错误和系统异常完全隔离，也不会触发不必要的全局异常处理逻辑。
• 不足：将错误信息伪装成正常业务返回值向下传递，后续如果流水线有其他处理正常业务结果的运算符，需要额外增加判断逻辑识别dummy值，否则很容易将错误信息当成正常结果处理，增加了后续逻辑的维护成本。

更符合响应式规范的最优实现 #

你提到的两种方案都有优化空间，响应式场景下处理这类条件中断的标准写法是通过Mono.error()传递自定义业务异常的错误信号，在当前流水线内就近处理业务异常，既不会出现dummy值污染正常流的问题，也不会把业务错误抛到全局：

// 先自定义业务异常，用于区分业务校验错误和系统异常
public class StepOneValidateFailException extends RuntimeException {
    public StepOneValidateFailException(String message) {
        super(message);
    }
}

@PostMapping(path = "/question")
public Mono<ResponseEntity<String>> standardImpl(String theImportantKey) {
    return WebClient.create("http://first-service.com/get" + theImportantKey).get()
            .exchangeToMono(clientResponse -> clientResponse.bodyToMono(String.class))
            .flatMap(extractGoodValueFromStepOne -> {
                if (extractGoodValueFromStepOne.startsWith("good")) {
                    System.out.println("Great! Step1 responded with something starting with good! Only with this we should invoke the second API");
                    return WebClient.create("http://second-service.com/get" + extractGoodValueFromStepOne.substring(4)).get()
                            .exchangeToMono(clientResponse -> clientResponse.bodyToMono(String.class));
                } else {
                    System.out.println("This is bad, Step 1 did not return something starting with good, no need to make the second API call then.");
                    // 走响应式错误信号传递自定义业务异常
                    return Mono.error(new StepOneValidateFailException("Step 1 did not answer with something good, the ultimate answer is an error"));
                }
            })
            .map(ResponseEntity::ok)
            // 就近处理当前业务的校验异常，其他系统异常继续向上抛
            .onErrorResume(StepOneValidateFailException.class, e -> Mono.just(ResponseEntity.ok(e.getMessage())));
}

这种写法的优势：

• 完全符合响应式流规范，所有信号都在响应式上下文中传递
• 业务错误和系统异常完全隔离，日志、监控可以做分类统计
• 错误处理逻辑和业务逻辑内聚在同一个方法里，不需要耦合全局异常处理器
• 正常业务流不需要处理额外的dummy值判断，逻辑更简洁

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