Spring WebFlux响应式管道异常处理疑问及代码优化咨询

问题1：认知误区解答 #

你的核心误区是混淆了响应式管道组装阶段和流订阅运行阶段的异常触发时机：

• 管道组装阶段指的是你链式调用Mono.just、map、doOnSuccess、onErrorResume等方法，拼接整个操作链的过程。如果在这个阶段直接抛出异常，此时onErrorResume还未被组装进操作链，确实无法捕获该异常。
• 你示例中validate方法写在doOnSuccess的回调函数中，这个回调不会在组装阶段执行，只有当请求触发Spring订阅当前Mono、上游发射成功信号到doOnSuccess节点时才会被调用。此时整个管道已经组装完成，doOnSuccess回调中抛出的异常会被Reactor框架自动捕获转换为错误信号向下游传递，自然会被下游的onErrorResume捕获处理，所以最终返回了降级后的Hi, Guest。

问题2：用Mono.error实现校验的写法 #

要使用Mono.error返回错误信号，需要将无返回值的doOnSuccess替换为可以转换流类型的flatMap操作符，改造示例如下：

@RestController
public class Example {

  @GetMapping("/greet")
  public Mono<String> test() {
     return Mono.just("Tim")
             .map(String::toUpperCase)
             .map(String::toLowerCase)
             .flatMap(this::validate) // 替换doOnSuccess，用flatMap处理校验逻辑
             .onErrorResume(ex -> Mono.just("Guest"))
             .map(s -> "Hi, "+s);
  }

  // 改造校验方法，返回响应式类型
  public Mono<String> validate(String s) {
    if(s.length() < 5) {
      return Mono.error(new RuntimeException("Name is short"));
    }
    return Mono.just(s);
  }
}

这种写法更符合响应式编程规范，避免在回调中直接抛出非受检异常，错误信号的传递也更可控。

代码优化建议 #

• 方法名遵守Java驼峰命名规范，示例中的Test方法改为小写开头的test
• 优先使用方法引用替代冗余Lambda，比如s -> s.toUpperCase()可以简化为String::toUpperCase
• 如果需要区分不同异常做差异化降级，可以在onErrorResume中增加类型判断，非业务异常直接抛出走全局异常处理：

  .onErrorResume(RuntimeException.class, ex -> {
      if ("Name is short".equals(ex.getMessage())) {
          return Mono.just("Guest");
      }
      // 其他异常继续向下传递，交给全局异常处理器返回标准错误响应
      return Mono.error(ex);
  })
  

• 通用校验逻辑可以抽成独立的函数式组件，方便多个业务流复用。

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