[External] : Re: Future.resultNow / exceptionNow

[Eric Kolotyluk]

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 an IllegalStateException.

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".
>
>
>