Open vlsi opened 4 years ago
+1 for bumping to 1.7 and calling addSuppressed
.
+1 for bumping -- why not directly to Java 8?
Well, I just saw you have 1.6, so 1.7 was a conservative suggestion.
On the other hand, both 1.7 and 1.8 are probably OK for me.
@marcphilipp , @sormuras , isn't this cool? https://github.com/vlsi/pgjdbc/runs/435902372#step:6:421
+1 for bumping to 1.7 and calling
addSuppressed
.
So then.... OpenTest4J 2.0.0 ?
I guess so.
@vlsi Would you be interested in submitting a PR?
Sometimes exceptions are passed through serialization, and it is not always the case that the receiver side has all the required classes to instantiate the exception.
For instance, when sending a SOAP response, one can't be sure that the receiver side would have
opentest4j
on the classpath. In the same way, Gradle uses serialization to pass exceptions between daemon processes. In those cases, the code uses standard APIs (e.g. getCause, getMessage, getStackTrace, ...) to snapshot the exception bits so it would be able to pass at least something meaningful. MultipleFailuresError does not exposecauses
viastandard
APIs, and it causes missing information in the test outputs.Note: Gradle (as of 6.1.1) results in creating a PlaceholderException instead of MultipleFailuresError.
Of course, Gradle does not know it
must
callMultipleFailuresError#getFailures
to get the causes.Suggestion: do something (e.g.
addSuppressed
) so the cause exceptions can be received via standard Java APIs.Note: if you can't bump minimal Java to 1.7, you might consider
SQLException#setNextException
. For instance, you might add adummy wrapper
SQLException
to the cause ofMultipleFailuresError
.