https://bz.apache.org/bugzilla/show_bug.cgi?id=69707
--- Comment #2 from Björn Kautler <bjo...@kautler.net> --- That's the nice thing, they are already part of the printed stacktrace, so you don't need to care. The bad thing is, that it is not really correct, as the exceptions are not suppressed, so semantically it is not the right thing to do. IntelliJ just prints the enclosed failures before printing the exception itself it seems. Gradle transforms the `MultipleFailuresError` into its own `DefaultMultiCauseException` (`https://github.com/gradle/gradle/blob/96495b6ca0d096dc849131a7796e44c6baff7606/platforms/core-runtime/stdlib-java-extensions/src/main/java/org/gradle/internal/exceptions/DefaultMultiCauseException.java) which then prints the wrapped throwables including stack trace in an overwritten `printStackTrace` method, so basically like with the suppressed exceptions, just with better semantics as they are printed as causes, not as suppressed exceptions. You could of course do something similar as Gradle is doing to have better semantics. I just said that the most trivial and quick fix would be to add the enclosed failures as suppressed exceptions like I do it in my work-around class I showed in #69687, it works fine, it just does not have the correct semantics. > How do you suggest to expose the "suppressed" failures/errors in XML? I don't > think this is a concept that is currently present inside the format. There are multiple ways you could consider. - You could add multiple `<failure>` and / or `<error>` tags, one for each wrapped throwable, but then you loose the message and stracktrace of the wrapper error which might also have relevant information. - You could add multiple `<failure>` and / or `<error>` tags, one for each wrapped throwable in addition to the one for the wrapper error, but you still loose the information about which throwables were linked together (at least if there could be multiple per test) - But actually, either printing the wrapped throwables separately like IntelliJ is doing, or as suppressed exceptions like my work-around is doing, or with a special exception like Gradle is doing and having the full output within that one `<failure>` or `<error>` node seems to be the most appropriate way to me. The content of the `<failure>` and `error` tags is not specified to any certain format afaik, so both, rendering all exceptions separately with blank lines separated, or rendering as part of the stacktrace both should be just fine imho. -- You are receiving this mail because: You are the assignee for the bug.
