上一篇[6、测试（3）]

下一篇[7.3、在调试模式下读取堆栈跟踪]

英文原文：https://projectreactor.io/docs/core/3.2.11.RELEASE/reference/#debugging
GitHub：https://github.com/jijicai/ProjectReactor/tree/master/book/Reactor3

7、调试 Reactor

从命令式和同步编程范式转换到反应式和异步编程范式有时会令人望而生畏。学习曲线中最陡峭的步骤之一是如何在出错时进行分析和调试。

在命令式环境中，调试通常是非常简单的：只要阅读 stacetrace，你就会发现问题的根源，以及更多：这完全是代码的失败吗？失败是否发生在某些库代码中？如果是，那么是代码的哪一部分调用了这个库，可能传入了错误的参数，最终导致了失败。

7.1、典型的 Reactor 堆栈跟踪

当切换到异步代码时，事情会变得更加复杂。

请考虑以下堆栈跟踪：

一个典型的 Reactor 堆栈跟踪

java.lang.IndexOutOfBoundsException: Source emitted more than one item
at reactor.core.publisher.MonoSingle$SingleSubscriber.onNext(MonoSingle.java:129)
at reactor.core.publisher.FluxFlatMap$FlatMapMain.tryEmitScalar(FluxFlatMap.java:445)
at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:379)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:121)
at reactor.core.publisher.FluxRange$RangeSubscription.slowPath(FluxRange.java:154)
at reactor.core.publisher.FluxRange$RangeSubscription.request(FluxRange.java:109)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.request(FluxMapFuseable.java:162)
at reactor.core.publisher.FluxFlatMap$FlatMapMain.onSubscribe(FluxFlatMap.java:332)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onSubscribe(FluxMapFuseable.java:90)
at reactor.core.publisher.FluxRange.subscribe(FluxRange.java:68)
at reactor.core.publisher.FluxMapFuseable.subscribe(FluxMapFuseable.java:63)
at reactor.core.publisher.FluxFlatMap.subscribe(FluxFlatMap.java:97)
at reactor.core.publisher.MonoSingle.subscribe(MonoSingle.java:58)
at reactor.core.publisher.Mono.subscribe(Mono.java:3096)
at reactor.core.publisher.Mono.subscribeWith(Mono.java:3204)
at reactor.core.publisher.Mono.subscribe(Mono.java:3090)
at reactor.core.publisher.Mono.subscribe(Mono.java:3057)
at reactor.core.publisher.Mono.subscribe(Mono.java:3029)
at reactor.guide.GuideTests.debuggingCommonStacktrace(GuideTests.java:995)

那里发生了很多事情。我们得到一个 IndexOutOfBoundsException，它告诉我们”源发出了多个项“。

我们可能很快就可以假设这个源是一个 Flux/Mono，正如下面提到 MonoSingle 的一行所证实的那样。所以这似乎是来自 single 操作符的抱怨。

参考 Mono#single 操作符的 Java 文档（Javadoc），我们看到 single 有一个契约：源必须恰好发出一个元素。看来我们有一个源发出了不止一个，因此违反了该契约。

我们能更深入地挖掘并找出源头吗？以下几行不是很有用。它们通过多次调用 subscribe 和 request ，带我们进入一个似乎是反应式链的内部。

通过浏览这些行，我们至少可以开始形成一幅出问题的链条的图片：它似乎涉及一个 MonoSingle、一个 FluxFlatMap 和一个 FluxRange（每个都在跟踪中得到几行，但总的来说涉及到这三个类）。所以一个 range().flatMap().single() 链可能吗？

但是如果我们在应用程序中经常使用这种模式呢？这仍然不能告诉我们太多，简单地寻找 single 并不能找到问题所在。最后一行是我们的一些代码。最后，我们接近了。

不过，等一下。当我们转到源文件时，我们看到的是一个预先存在的 Flux 被订阅了，如下所示：

toDebug.subscribe(System.out::println, Throwable::printStackTrace);

所有这些都发生在订阅的时候，但是 Flux 自身并没有被声明。更糟糕的是，当我们到变量声明的地方时，我们看到：

public Mono<String> toDebug; //please overlook the public class attribute

该变量在声明的地方没有被实例化。我们必须假设最坏的情况，即我们发现可能有几个不同的代码路径在应用程序中设置它。我们仍然不确定是哪一个引起了这个问题。

注释：这类似于 Reactor 的运行时错误，而不是编译错误。

我们想更容易找出的是操作符在哪里被加入到链中——也就是说，Flux 在哪里被声明。我们通常称之为 Flux 的组装。

7.2、激活调试模式

尽管堆栈跟踪仍然能够为有经验的人传递一些信息，但是我们可以看到，在更高级的情况下，它本身并不理想。

幸运的是，Reactor 提供了一个面向调试的装配时仪表功能。

这是通过在应用程序启动时定制 Hooks.onOperator 钩子来完成的（或者至少在引入的 Flux 或 Mono 可以被实例化之前），如下所示：

Hooks.onOperatorDebug();

这将通过包装操作符的结构并捕获那里的堆栈跟踪来开始检测对 Flux（和 Mono）操作符的调用（在那里它们被组装到链中）。由于这是在声明操作符链时完成的，所以应该在此之前激活钩子，所以最安全的方法是在应用程序开始时激活它。

稍后，如果发生异常，则失败的运算符可以引用该捕获并将其附加到堆栈跟踪。

在下一节中，我们将了解堆栈跟踪的不同之处以及如何解释这些新信息。

上一篇[6、测试（3）]

下一篇[7.3、在调试模式下读取堆栈跟踪]