[External] : Re: Future.resultNow / exceptionNow

[Brian Goetz]

On 11/21/2021 1:57 PM, Eric Kolotyluk wrote:
> Just to clarify...
>
> "(optional) deal with results and errors"
>
> If you want to call Future::resultNow then dealing with errors first 
> is not optional, or you are inviting anIllegalStateException.

I think you may have mis-parsed my sentence?  "Optional" applies to the 
whole sentence; for many tasks, there is no result, only side-effects, 
so there's no need to deal with results, so no need to call 
Future::resultNow (in fact, likely no need for keeping the futures at 
all in this case.)

Again, as Ron has pleaded: PLEASE TRY IT, rather than critiquing in a 
vacuum; designing concurrency APIs is hard, and doubly so when new 
paradigms are involved.  If you are having trouble figuring out how to 
try it, ask questions!

Cheers,
-Brian



>
> On Sun, Nov 21, 2021 at 10:49 AM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>
>     > When you throw an exception*because of another exception*  it is
>     far better
>     > to add it as the cause, than to throw one with no cause. If you
>     don't
>     > include the cause, you are hiding the root issue that needs to
>     be solved.
>     > Yes, we may be using the API improperly, but are trying to teach
>     people to
>     > use the API properly, or are you just trying to make it annoying
>     if they
>     > _don't_  use it properly?
>
>     The API is designed to follow a simple pattern:
>
>          create an SE, always in a TWR header
>          fork some tasks
>          wait for them all to finish (there's a method for this)
>          (optional) deal with results and errors, if needed, in
>     accordance
>     with selected error-handling policy
>          implicitly close by falling out of TWR
>
>     In most cases, this will fit on half a page or less of code.
>
>     We don't strictly need resultNow, but if we didn't add it, people
>     would
>     complain that gathering results with Future is annoying (and
>     they'd be
>     right) because Future forces you to deal with all the possible
>     states,
>     often by catching exceptions, even though, if you follow the above
>     simple pattern, you *already* know what state the Future is in.  [1]
>
>     It's natural to ask "but how can I be sure", but the API is
>     designed to
>     be simple enough that it is *hard to get wrong*, once you learn the
>     idiom once.  Three phases: fork tasks, wait for tasks, optionally
>     handle
>     results.  Given that, it will surely be annoying if there is any
>     gratuitous unpacking friction; it will feel like needing both belt
>     and
>     suspenders.  Wrapping the result in Optional is less annoying than
>     dealing with the exceptions of Future, but its still annoying, and,
>     still unnecessary.  (And, if we did wrap it in an Optional, the same
>     complaint about "why is the optional empty, you should wrap the
>     exception" would come up.  At which point we've reinvented the
>     existing
>     Future::get API.)
>
>     As Ron has suggested several times, rather than redesigning the
>     API in a
>     vacuum, its probably best to *go try it* and report back your
>     experience.  Much of what comes out of Project Loom involves
>     unlearning
>     things we had to do before because of accidental constraints like
>     "threads are expensive to create."  The idioms we have
>     internalized are
>     conditioned by the reality we used to be stuck with, but no longer
>     are.
>     The natural idioms we will equilibrate to after such a big change in
>     cost model may be slightly unintuitive at first, but give them a
>     chance.
>
>
>
>
>
>     [1] If your policy is complicated, it may require some bookkeeping to
>     sort the succeeded from failed tasks, but that's what the handler
>     object
>     is for, and it's easy to write handlers even for complex policies
>     like
>     "abort if two red tasks succeed before three blue tasks fail".
>
>