并行流中异常细节不一致

Question

并行流中异常细节不一致

7

大多数情况下，在并行流中抛出的异常不会具有其所有属性。例如：

@Test
public void test() {
    assertThatThrownBy(() -> Stream.of("1", "2", "asdf").parallel().forEach(Integer::parseInt))
            .asInstanceOf(InstanceOfAssertFactories.type(NumberFormatException.class))
            .extracting("detailMessage")
            .isEqualTo("For input string: \"asdf\"");
}

这通常会失败，而这样做：

@Test
public void test() {
    assertThatThrownBy(() -> Stream.of("1", "2", "asdf").forEach(Integer::parseInt))
            .asInstanceOf(InstanceOfAssertFactories.type(NumberFormatException.class))
            .extracting("detailMessage")
            .isEqualTo("For input string: \"asdf\"");
}

成功率为100%。

另一件事是当消息缺失时，异常的原因中将会出现该消息。例如：

@Test
public void test() {
    assertThatThrownBy(() -> Stream.of("1", "2", "asdf").parallel().forEach(Integer::parseInt))
            .asInstanceOf(InstanceOfAssertFactories.type(NumberFormatException.class))
            .extracting("cause.detailMessage")
            .isEqualTo("For input string: \"asdf\"");
}

有没有什么办法可以让并行流抛出确切的异常，而不是一些嵌套的异常呢？

- dlhextall

它在一个你没有处理的线程中崩溃，因此错误信息不会详细显示。它失败的方式就像在另一个线程的Runnable中一样。 - eduyayo

3

即使Integer.parseInt的文档没有指定特定的异常消息格式，因此在并行处理期间该消息被转换的事实是无关紧要的。应用程序代码不应依赖于特定的消息格式，由于您的单元测试应该测试您的应用程序代码，因此在单元测试中也不应有测试未指定的消息格式的要求。 - Holger

@Holger 将 .isEqualTo(...); 替换为 .isNotNull();，你将得到相同的结果。这里的问题不在于字符串的内容，而是它完全为空。 - dlhextall

1

文档也没有说明您可以期望一个非空的消息。 - Holger

1

@Holger 但作为消费者，难道不应该期望这种行为保持一致，即使没有记录或保证吗？（依赖于OP在发生时陈述它是“大多数时间”） - Naman

1

@Naman 它是 RuntimeException 的一个子类型，通常被认为是必须修复的编程错误的症状。对于这些错误，只要人类程序员能够识别问题即可，无论消息是否直接显示或记录在原因中都已足够。它们不适合自动处理。对于应用程序逻辑的自动化测试，只要知道无效输入不会悄无声息地通过即可。 - Holger

2个回答

0

也许你正在接收一个异常，它被另一种类型的异常包装，而parallel()抛出了更多信息和你要查找的实际异常在getCause()或getSupperessed()中。

外部异常具有的附加信息可能是流中引发异常的项目数量（例如，“3个中的1个”）或类似的内容。

- selalerer

是的，它被包装了，因此第三个例子，但不应该。非并行流异常永远不会被包装。 - dlhextall

@loeuf17 你确定它不应该吗？我对并行流不是很熟悉，但是是否有承诺要具有与非并行流完全相同的行为，包括异常处理？ - selalerer

1

也许它应该被包装起来，但是根据我的测试，它并不总是被包装。大约70%的时间它会被包装，而30%的时间则不会。 - dlhextall

1

也许它同时使用你运行命令的线程和线程池，当异常发生在你的线程上时，你会收到原始异常，但当它发生在线程池中的线程上时，你会收到一个包装过的异常。 - selalerer

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，

- Stuart Marks · Accepted Answer

并行流的执行由一组任务组成，这些任务被分配给多个线程，其中一些线程来自于fork-join池（通常是fork-join公共池），也包括调用线程。将任务分配给线程的过程是不确定的，因此某个任务（比如在"asdf"上调用parseInt）可能会在线程池中的某个线程上执行，也可能在调用线程上执行，你无法控制哪个线程执行任何给定的任务。这个特定的任务抛出了一个异常，所以问题是当不同的线程发生异常时如何处理。

如果任务在调用线程上执行（并抛出异常），其他任务将被取消，并将异常重新抛出给调用者。如果任务在线程池线程上执行，异常将被捕获，其他任务将被取消，并将异常包装在一个新异常中（如果可能，则为相同类型），然后从调用线程抛出。实现此功能的代码有一个注释来描述它所做的事情：

/**
 * Returns a rethrowable exception for the given task, if
 * available. To provide accurate stack traces, if the exception
 * was not thrown by the current thread, we try to create a new
 * exception of the same type as the one thrown, but with the
 * recorded exception as its cause. If there is no such
 * constructor, we instead try to use a no-arg constructor,
 * followed by initCause, to the same effect. If none of these
 * apply, or any fail due to other exceptions, we return the
 * recorded exception, which is still correct, although it may
 * contain a misleading stack trace.
 *
 * @return the exception, or null if none
 */
private Throwable getThrowableException() { ... }

这种包装的原因是为了保留关于异常被捕获的位置信息，可以追溯到调用代码。如果抛出异常的任务直接在调用线程上执行，则堆栈跟踪包括从实际任务执行一直回溯到调用者的帧。如果抛出异常的任务是来自线程池线程，则该异常的堆栈跟踪终止于 fork-join 框架。封装的异常提供了额外的帧，这些帧会导致返回到调用者。如果不进行包装，则来自线程池线程的堆栈跟踪将不完整，并且可能很难确定异常的根本原因。下面是一个发生在调用线程上的异常堆栈示例：

Exception in thread "main" java.lang.NumberFormatException: For input string: "asdf"
    at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.base/java.lang.Integer.parseInt(Integer.java:652)
    at java.base/java.lang.Integer.parseInt(Integer.java:770)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
    at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
    at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.helpCC(ForkJoinPool.java:1115)
    at java.base/java.util.concurrent.ForkJoinPool.externalHelpComplete(ForkJoinPool.java:1957)
    at java.base/java.util.concurrent.ForkJoinTask.tryExternalHelp(ForkJoinTask.java:378)
    at java.base/java.util.concurrent.ForkJoinTask.externalAwaitDone(ForkJoinTask.java:323)
    at java.base/java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:412)
    at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:736)
    at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
    at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
    at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
    at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:661)
    at ParallelStreamExceptions.main(ParallelStreamExceptions.java:31)

这里是一个从线程池线程引发的异常的堆栈跟踪示例：

Exception in thread "main" java.lang.NumberFormatException
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
    at java.base/java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:603)
    at java.base/java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:678)
    at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:737)
    at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
    at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
    at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
    at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:661)
    at ParallelStreamExceptions.main(ParallelStreamExceptions.java:31)
Caused by: java.lang.NumberFormatException: For input string: "asdf"
    at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.base/java.lang.Integer.parseInt(Integer.java:652)
    at java.base/java.lang.Integer.parseInt(Integer.java:770)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
    at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
    at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
    at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)

请注意，在这些堆栈跟踪中，唯一可见的应用程序代码是方法 `ParallelStreamExceptions.main`；其余部分是库代码。如果异常在调用线程上，则这很简单明了。但考虑一下，如果线程池线程中的原始异常仅被重新抛出到调用线程中，而没有进行包装，那么这可能会“误导”，正如注释所说，因为它根本不包含应用程序的堆栈帧！因此，包装异常提供了缺失的上下文。现在，对于单元测试该怎么办呢？有几种替代方案。一种就是只检查异常类型而不是其详细消息。在这个例子中，检查 `NumberFormatException` 应该可以适用于任何线程抛出异常。第二种，如果您真的想检查详细消息，可以编写一个自定义断言来实现。可能有一个惯用的 AssertJ 方式来编写这个，但逻辑大致是“断言捕获的异常是具有预期详细消息的 NumberFormatException，或者捕获的异常具有一个作为原因的具有预期详细消息的 NumberFormatException”。第三种，您可能需要重新考虑您在这里测试什么。流执行框架正在执行每个流元素的解析为 int 的工作。这个示例使用 `Integer::parseInt`，但我假设这是一些执行一些复杂工作的应用程序代码的替代品。单元测试的目的应该是针对各种输入测试应用程序代码，而不是测试流执行框架。