[concurrency-interest] Future.isCompletedNormally Future.isCompletedAbnormally

Martin Buchholz martinrb at google.com
Mon Mar 9 12:45:40 EDT 2015


I don't think the names of the existing methods is great, but it's not
terrible, and the time for bike shedding the names is past.
(We should have objected when Doug introduced these methods)
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/CompletableFuture.html#getNow-T-
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/ForkJoinTask.html#isCompletedNormally--
I just noticed this method that Luke wants:
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/ForkJoinTask.html#getException--



On Sat, Mar 7, 2015 at 3:32 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> More comments and suggestions
>
> 1. I think "isCompletedAbnormally" is confusing in relation to the
> existing method isCancelled.  Is cancellation an abnormal completion?  I
> think this is debatable and therefore a point of confusion.  I think these
> names are clearer:
>
> hasFailed()
> hasCompletedWithException()
>
> 2. hasCompletedNormally instead of isCompletedNormally?
>
> 3. Would a non-blocking sibling of get() be a more basic building block
> for these methods? For example:
>
> getOptional() returns an Optional that is present if f.isDone, empty if
> !f.isDone, and otherwise throws the usual exceptions?  (Except it does
> *not* throw InterruptedException?)
>
> --Joe
>
> On Sat, Mar 7, 2015 at 2:27 PM, Luke Sandberg <lukeisandberg at gmail.com>
> wrote:
>
>> I think these would be pretty useful (isCancelled() is pretty useful), I
>> would also be interested in efficient methods to get the failure cause of a
>> future (without paying the cost of an ExecutionException).  A lot of time
>> the executionexception contains no useful information (if a library is
>> dereferencing a users future), and so i end up discarding the EE or
>> replacing it with something more useful.
>>
>> On Thu, Mar 5, 2015 at 11:58 AM, Martin Buchholz <martinrb at google.com>
>> wrote:
>>
>>> Perhaps Doug can explain why isCompletedNormally and
>>> isCompletedAbnormally landed in ForkJoinTask but no other Future
>>> implementation.
>>>
>>> On Thu, Mar 5, 2015 at 11:07 AM, thurstonn <thurston at nomagicsoftware.com
>>> > wrote:
>>>
>>>>
>>>> > All of the is* methods would (obviously) have the same happens-before
>>>> > semantics.
>>>>
>>>> But that's deliberate - isDone() can't have any specified memory
>>>> consistency
>>>> rules, since
>>>> the following **doesn't** hold:
>>>>  isDone == true iff isCompletedNormally() == true
>>>>
>>>>
>>> I don't see why that's true.  I expect the action in the thread that
>>> makes the future done (setting result or exceptional value) happens-before
>>> actions isDone returning true
>>>
>>>
>>>> The usefulness of isCompletedNormally() would lie exactly in this, e,g,
>>>>
>>>> if (f.isCompletedNormally())
>>>>    do something  //all done
>>>> else if (waitedlongenough())
>>>>    f.cancel()
>>>>    schedule a backup/replacement execution
>>>>
>>>>
>>> I don't think eliding the try/catch block is good motivation.
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>
>> _______________________________________________
>> 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/20150309/fe1646d8/attachment.html>


More information about the Concurrency-interest mailing list