Improve C/R exception printout

[rvansa]

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)

---

Progress

• Change must not contain extraneous whitespace

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/crac.git pull/145/head:pull/145
$ git checkout pull/145

Update a local copy of the PR:
$ git checkout pull/145
$ git pull https://git.openjdk.org/crac.git pull/145/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 145

View PR using the GUI difftool:
$ git pr show -t 145

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/crac/pull/145.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back rvansa! A progress list of the required criteria for merging this PR into crac will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@rvansa This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

Improve C/R exception printout

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 2 new commits pushed to the crac branch:

• 93000a3: Adjusting CRaC tests
• a3d56c2: 8321660: [CRaC] Trim native heap before checkpoint to decrease image size

Please see this link for an up-to-date comparison between the source branch of this pull request and the crac branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the crac branch, type /integrate in a new comment.

[mlbridge]

Webrevs

• 01: Full - Incremental (5f011c94)
• 00: Full (474b1638)

[bridgekeeper]

@rvansa This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[rvansa]

@AntonKozlov Could you review please?

[AntonKozlov]

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]

crac/src/java.base/share/classes/jdk/crac/package-info.java

Line 63 in 474b163

* Exceptions from restore notification are provided as suppressed ones by a {@code RestoreException} (in a sense of {@link Throwable#addSuppressed}).

[rvansa]

"Nested" is probably a better term than "inner". Having method getNestedExceptions() that actually calls getSuppressed() would be trivial, and would provide space for javadocs. A completely distinct field is probably cleaner, though; however it feels that we are getting more code duplicated for Checkpoint and RestoreException; do you think it would be useful to have them share a common parent? (ofc. we will still have some duplication with the javax.crac package...).

[AntonKozlov]

I also would prefer "nested" exceptions not to overlap with suppressed in implementation, to make sure the correct interface is always called. Indeed, a common parent class makes sense, and sometime in handling of the exception I had to write

catch (CheckpointException | RestoreException e) { ... }

Which is probably correct way to indicate both checkpoint and restore failures are handled there. But if you want to just to print the "nested" exception, apprantly you'll need a common base exception. I.e. a common base looks good.

[bridgekeeper]

@rvansa This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[rvansa]

@AntonKozlov Updated, dropping all use of suppressed exceptions.

[bridgekeeper]

@rvansa This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[rvansa]

Still relevant.

[bridgekeeper]

@rvansa This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[rvansa]

Still relevant, waiting for @AntonKozlov review.

[bridgekeeper]

@rvansa This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!