crac
crac copied to clipboard
openjdk
Improve C/R exception printout
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
- [x] 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
:wave: 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.
![bridgekeeper[bot] avatar](https://avatars.githubusercontent.com/u/41768318?v=4 "Published by a pub.dev verified publisher"){kind=small}
@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:
- 93000a3cbf357983f9f74b5a15b1efd33f272368: Adjusting CRaC tests
- a3d56c25eb2b68779a66145bb8d9d443f13c1d68: 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.
@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!
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
"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...).
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.
@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 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 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 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 This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.
@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 This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.
@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 This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.