并行流中的异常详细信息不一致

Question

大多数情况下，并行流中引发的异常不会具有其所有属性。

前任：

@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"");
}

知道如何使并行流抛出确切的异常而不是某种嵌套的怪物吗？

Answer 1

并行流的执行由一组任务组成，这些任务分布在多个线程中，其中一些来自分叉连接池(通常是分叉联接公共池(，还包括调用线程。任务到线程的分配是不确定的，因此给定的任务(如在"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但我假设这是某些执行一些复杂工作的应用程序代码的替代项。单元测试的重点应该是针对各种输入测试应用程序代码，而不是测试流执行框架。

Answer 2

也许您收到的异常被另一种类型的异常包装，parallel()抛出更多信息，而您正在寻找的实际异常是getCause()或getSupperessed()。

外部异常具有的附加信息可能是流中通过异常的项目数量(例如"1/3"(或类似的东西。