[concurrency-interest] CompletableFuture.whenComplete survey

Joe Bowbeer joe.bowbeer at gmail.com
Mon Dec 21 16:49:11 EST 2015


Continuing my prose, an additional sentence can be added specifically for
the case we are voting on, replacing the final sentence with these two:

"If this stage completed normally but the supplied action itself encounters
an exception, then the returned stage exceptionally completes with the
supplied action's exception. If this stage completed exceptionally and the
supplied action encounters an exception, then the returned stage
exceptionally completes with [...]"

On Mon, Dec 21, 2015 at 1:18 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> Given that the doc leads with the statement that whenComplete "returns a
> new CompletionStage with the same result or exception as this stage", I
> think the following is sufficiently clear:
>
> If this stage completed normally but the supplied action itself encounters
> an exception, then the returned stage exceptionally completes with the
> supplied action's exception.
>
> On Mon, Dec 21, 2015 at 1:05 PM, Joe Bowbeer <joe.bowbeer at gmail.com>
> wrote:
>
>> Some disambiguation of "this" is needed, especially when it is referring
>> to different stages or their things.
>>
>> Using input/output would help, except that it is normal in javadoc to
>> refer to the object whose method is being invoked as "this [thing]". In the
>> case of CompletionStage#whenComplete, "this stage" is this CompletionStage
>> object.
>>
>> Here is my stab at a clearer sentence:
>>
>> "If the supplied action itself encounters an exception, then the returned
>> stage exceptionally completes with the supplied action's exception unless
>> this stage [had|already] completed exceptionally, in which case the first
>> exception is retained.
>>
>>
>> On Mon, Dec 21, 2015 at 12:36 PM, Chris Purcell <
>> chris.purcell.39 at gmail.com> wrote:
>>
>>> Perhaps a simple change from "this stage/the returned stage" to "the
>>> input stage/the output stage" would be helpful?
>>>
>>> Chris
>>>
>>> On Mon, 21 Dec 2015 at 19:37 Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
>>>
>>>> Thanks for clarifying!
>>>>
>>>> I had to read the spec several more times before I could parse that
>>>> meaning, but now that I see it, it is also hard to mistake :-)
>>>>
>>>> The spec talks about "this stage" and the "returned stage" and I was
>>>> confused by all the "this".
>>>>
>>>> In the spec wording, below, "this stage" is stage1 throwing exception1
>>>> and the "returned stage" is stage2 throwing exception2. The last phrase
>>>> contains a "this exception" referring to exception2 and also a "this stage"
>>>> referring to stage1, which is especially confusing.
>>>>
>>>> Annotated:
>>>>
>>>> "If the supplied action [action2] itself encounters an exception
>>>> [exception2], then the returned stage [stage2] exceptionally completes with
>>>> this exception [exception2] unless this stage [stage1] also completed
>>>> exceptionally [exception1]."
>>>>
>>>> I had been interpreting the final "this stage" to mean the next stage...
>>>>
>>>> Given my new understanding of the spec, throwing exception1 with
>>>> suppressed exception2 (a la try-with-resources) makes a lot of sense.
>>>>
>>>> To be clear, is the current jdk8 behavior *not* compliant with spec?
>>>>
>>>>
>>>> On Mon, Dec 21, 2015 at 10:49 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>>>>
>>>>> On 12/21/2015 01:12 PM, joe.bowbeer at gmail.com wrote:
>>>>>
>>>>>> In the second survey email, the only options clearly *compatible*
>>>>>> with the
>>>>>> CompletionStage spec are ...
>>>>>>
>>>>>
>>>>> No. Here's jdk8 spec:
>>>>>
>>>>> "If the supplied action itself encounters an exception, then the
>>>>> returned stage exceptionally completes with this exception unless this
>>>>> stage also completed exceptionally."
>>>>>
>>>>> Which describes options A and B. Option B also adds as suppressed
>>>>> the whenComplete exception, which is not required but not disallowed
>>>>> by current spec.
>>>>>
>>>>> Options C would comply only if the "unless" clause were dropped.
>>>>>
>>>>> Options D and E would require more changes.
>>>>>
>>>>> where, as a reminder...
>>>>>
>>>>>   CompletableFuture<String> f1 = CompletableFuture.supplyAsync(() -> {
>>>>>      if (true)
>>>>>         throw new FirstException();
>>>>>      else
>>>>>         return "A";
>>>>>    });
>>>>>
>>>>>   CompletableFuture<String> f2 = f1.whenComplete((result, exception)
>>>>> -> {
>>>>>     if (true)
>>>>>        throw new SecondException();
>>>>>    });
>>>>>
>>>>> A. The FirstException. In other words, preserve the source outcome
>>>>> (only) if exceptional, ignoring the SecondException.
>>>>>
>>>>> B. The FirstException, with the SecondException as its suppressed
>>>>> exception.  In other words, preserve but modify the source exception to
>>>>> record the SecondException.
>>>>>
>>>>> C. The SecondException. In other words, replace the source outcome
>>>>> (whether it is exceptional or not).
>>>>>
>>>>> D. The SecondException, with the FirstException as its suppressed
>>>>> exception.  In other words, replace the source outcome, but if exceptional,
>>>>> record it as a suppressedException of the SecondException.
>>>>>
>>>>> E. A new CompletionException, with the FirstException as its cause and
>>>>> the SecondException as its suppressed exception. In other words, indicate
>>>>> that throwing an exception in whenComplete is a different form of error.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Concurrency-interest mailing list
>>>> Concurrency-interest at cs.oswego.edu
>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151221/d5bceffa/attachment.html>


More information about the Concurrency-interest mailing list