-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8312436: CompletableFuture never completes when 'Throwable.toString()' method throws Exception #18988
Conversation
👋 Welcome back vklang! A progress list of the required criteria for merging this PR into |
@viktorklang-ora 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:
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 527 new commits pushed to the
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 |
@viktorklang-ora The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
* String {@code "Completed normally"} or the String {@code | ||
* "Completed exceptionally"}, or the String {@code "Not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two looks like a discrepancy between spec and implementation, and it seemed safer to amend the spec rather than the implementation, as code might be relying on actual behavior rather than the spec:ed one.
@DougLea You might have some thoughts to offer on this :)
@@ -2623,7 +2667,7 @@ public String toString() { | |||
? "[Not completed]" | |||
: "[Not completed, " + count + " dependents]") | |||
: (((r instanceof AltResult) && ((AltResult)r).ex != null) | |||
? "[Completed exceptionally: " + ((AltResult)r).ex + "]" | |||
? "[Completed exceptionally: " + ((AltResult)r).ex.getClass().getName() + "]" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DougLea @AlanBateman It seemed safer to switch to outputting the cause FQCN rather than wrapping in a try-catch and trying to come up with a fallback text.
The reason for amending this is for things like JShell, results are toString():ed which would mean that the current session would break if toString():ing the result throws (also further signalling that throwing on toString() seems unreasonable in general).
// This makes sure that CompletableFuture still behaves appropriately | ||
// even if thrown exceptions end up throwing exceptions from their String | ||
// representations. | ||
@Override public String getMessage() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I decided to do this to make sure that all pre-existing test cases would still work even if the exception used has a misbehaving toString() (toString() transitively calls getLocalizedMessage() which in turn calls getMessage())
static CompletionException wrapInCompletionException(Throwable t) { | ||
if (t == null) | ||
return new CompletionException(); | ||
|
||
String message; | ||
Throwable suppressed; | ||
try { | ||
message = t.toString(); | ||
suppressed = null; | ||
} catch (Throwable unknown) { | ||
message = ""; | ||
suppressed = unknown; | ||
} | ||
|
||
final CompletionException wrapping = new CompletionException(message, t); | ||
|
||
if (suppressed != null) | ||
wrapping.addSuppressed(suppressed); | ||
|
||
return wrapping; | ||
} | ||
|
||
static ExecutionException wrapInExecutionException(Throwable t) { | ||
if (t == null) | ||
return new ExecutionException(); | ||
|
||
String message; | ||
Throwable suppressed; | ||
try { | ||
message = t.toString(); | ||
suppressed = null; | ||
} catch (Throwable unknown) { | ||
message = ""; | ||
suppressed = unknown; | ||
} | ||
|
||
final ExecutionException wrapping = new ExecutionException(message, t); | ||
|
||
if (suppressed != null) | ||
wrapping.addSuppressed(suppressed); | ||
|
||
return wrapping; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the main thing—and the big question is if this approach is the best path or not.
@@ -306,13 +306,57 @@ final boolean completeValue(T t) { | |||
return RESULT.compareAndSet(this, null, (t == null) ? NIL : t); | |||
} | |||
|
|||
static CompletionException wrapInCompletionException(Throwable t) { | |||
if (t == null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any preexisting code path that ever passes a null? If not I don't think this check is necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opted to be more safe than sorry. Since this is on the failure-path it isn't performance critical so I think affording a null-check is fine.
@AlanBateman Do you have a minute to review this one? |
/integrate |
Going to push as commit 326dbb1.
Your commit was automatically rebased without conflicts. |
@viktorklang-ora Pushed as commit 326dbb1. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Will this be backported to JDK21U? |
Primarily offering this PR for discussion, as Throwables throwing exceptions on toString(), getLocalizedMessage(), or getMessage() seems like a rather unreasonable thing to do.
Nevertheless, there is some things we can do, as witnessed in this PR.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/18988/head:pull/18988
$ git checkout pull/18988
Update a local copy of the PR:
$ git checkout pull/18988
$ git pull https://git.openjdk.org/jdk.git pull/18988/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 18988
View PR using the GUI difftool:
$ git pr show -t 18988
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/18988.diff
Webrev
Link to Webrev Comment