On Mon, 13 May 2024 17:03:00 GMT, Chen Liang <li...@openjdk.org> wrote:
>> This change adds wrapping of the CancellationException produced by
>> CompletableFuture::get() and CompletableFuture::join() to add more
>> diagnostic information and align better with FutureTask.
>>
>> Running the sample code from the JBS issue in JShell will produce the
>> following:
>>
>>
>> jshell> java.util.concurrent.CancellationException:
>> at
>> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
>> at
>> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
>> at REPL.$JShell$18.m2($JShell$18.java:10)
>> at REPL.$JShell$17.m1($JShell$17.java:8)
>> at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
>> at java.base/java.lang.Thread.run(Thread.java:1575)
>> Caused by: java.util.concurrent.CancellationException
>> at
>> java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
>> at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
>> ... 1 more
>
> src/java.base/share/classes/java/util/concurrent/CancellationException.java
> line 72:
>
>> 70: * @param cause the underlying cancellation exception
>> 71: */
>> 72: CancellationException(String message, CancellationException cause) {
>
> Can we remove the message argument, which is always empty?
Good question. So what I did was to initially omit it, but then the message
becomes the type of the cause, which didn't look right. Then I passed in the
empty-string in the constructor, but that seemed too restrictive, since the
overload is for in-package use only, I opted for some flexibility in case we
want to customize the message on `get` vs `join`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19219#discussion_r1598788602
