MultipleFailuresError loses exceptions in re-serialization scenarios

[vlsi]

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 expose causes via standard 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 call MultipleFailuresError#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 a dummy wrapper SQLException to the cause of MultipleFailuresError.

[marcphilipp]

+1 for bumping to 1.7 and calling addSuppressed.

[sormuras]

+1 for bumping -- why not directly to Java 8?

[vlsi]

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.

[vlsi]

@marcphilipp , @sormuras , isn't this cool? https://github.com/vlsi/pgjdbc/runs/435902372#step:6:421

[sbrannen]

+1 for bumping to 1.7 and calling addSuppressed.

So then.... OpenTest4J 2.0.0 ?

[marcphilipp]

I guess so.

[marcphilipp]

@vlsi Would you be interested in submitting a PR?