[crac] RFR: Improve C/R exception printout

[Anton Kozlov]

On Fri, 24 Nov 2023 09:04:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Some users might get confused by the inner exceptions reported during C/R as *suppressed* exceptions. This PR changes the printout to make it look as if the exception had multiple causes. For example the DryRunTest will report this:
> 
> jdk.crac.CheckpointException: Failed with 2 inner exceptions
> Cause 1/2: java.lang.RuntimeException: should not pass
> 	at DryRunTest$CRResource.beforeCheckpoint(DryRunTest.java:47)
> 	at java.base/jdk.crac.impl.AbstractContext.invokeBeforeCheckpoint(AbstractContext.java:44)
> 	... (redacted)
> Cause 2/2: jdk.crac.impl.CheckpointOpenFileException: /tmp/jtreg-DryRunTest6956725915963168340.tmp
> 	at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$1(JDKFileResource.java:89)
> 	at java.base/jdk.crac.Core.checkpointRestore1(Core.java:174)
>         ... (redacted)

Thanks. I agree that reporting exceptions as suppressed may be confusing. The new report looks good. But it introduces a new term "inner" which is not specified anywhere. Another side of the same problem is that programmatic access to the "inner" exception still remains through getSuppressed(), per javadoc and the fact there is no other mean to get an inner exception. I would suggest to go away completely from suppression (which was introduced for try-with-resources) to a completely distinct mechanism to record inner/nested/causing exceptions for Checkpoint... or RestoreException. How does it sound? My point is to have a mechanism that is consistent in 1) user-visible report; 2) in programmatic API; 3) the textual part of javadoc specification, e.g. package-level javadoc [1]. 

[1]https://github.com/openjdk/crac/blob/474b1638568a1a84b10d3b0a821e5d6e37f9eeae/src/java.base/share/classes/jdk/crac/package-info.java#L63

-------------

PR Comment: https://git.openjdk.org/crac/pull/145#issuecomment-1874246068