[External] : Re: Future.resultNow / exceptionNow

[Alex Otenko]

Correct, hence the fuss around state != SUCCESS for the opposite condition.

As for examples of when you'd need this - I think commonly I want to start
processing the responses as soon as they start arriving, not wait for them
all to complete.

Maybe in this brave new world things just get expressed differently, but I
would need something like "wait for the first" (that's "any" semantics),
process, then "wait for the next", etc. Processing like this is more
efficient than waiting for all, then process all, and less complex than
processing each response in the task, as there is no concurrency in
sequential processing of responses.

Alex

On Mon, 22 Nov 2021, 11:06 Ron Pressler, <ron.pressler at oracle.com> wrote:

>
>
> > On 21 Nov 2021, at 21:27, Alex Otenko <oleksandr.otenko at gmail.com>
> wrote:
> >
> > I view it the other way around. Since it is guarding resultNow, should
> preclude all failures, which means FAILED or CANCELLED (we already know it
> is not RUNNING).
> >
>
> The only thing that can guard resultNow is `if (f.state() ==
> State.SUCCESS)`, but you’ve taken this discussion to the issue of polling
> futures. Let’s get back to StructuredExecutor, which should not require
> polling the future or guarding resultNow except in the special cases I
> mentioned.
>
> — Ron
>
>
>