[External] : Re: Future.resultNow / exceptionNow

[Brian Goetz]

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