[External] : Re: Future.resultNow / exceptionNow

[Ron Pressler]

You *do* know what went wrong, because the exception tells you the actual state of the future. It essentially says, expected state X but I’m in state Y. And as to polling, you do have that: the state method.

If we only had maybeResultNow that returned an Optional, that would create a problem: code that knows what the state is — such as the very code that uses StructuredExecutor — would have to match on the Optional unnecessarily (or call get() which would be both more cumbersome, and, if fails, would be much less informative than the situation now). I don’t, however, see the problem that you want to solve with the feature you wish to add.

— Ron

On 21 Nov 2021, at 11:54, Alex Otenko <oleksandr.otenko at gmail.com<mailto:oleksandr.otenko at gmail.com>> wrote:

Sure. You have the advantage of trying this design with a large project like JDK perhaps :) I have only a few dummy programs trying to get to edge cases.

My feedback is that throwing ISA is not to my liking. I would prefer these methods to be polling in nature, not prescribing what catches are good.

For example, I agree with Rémi to the extent that the cause better be mentioned somewhere on stack trace, even though I don't think we should rely on where exactly it is. The reason for this is experience in supporting cloud deployments. The program may be broken by your standards, but I would prefer to know a bit more than just that _something_ went wrong, especially since exposing that is cheap.


Alex

On Sun, 21 Nov 2021, 11:36 Ron Pressler, <ron.pressler at oracle.com<mailto:ron.pressler at oracle.com>> wrote:


> On 21 Nov 2021, at 11:32, Ron Pressler <ron.pressler at oracle.com<mailto:ron.pressler at oracle.com>> wrote:
>
> Perhaps it might be better to have both resultNow and exceptionNow fail in three of the four states.
> Some convenience methods could be added to the State enum rather than to Future.
>
> — Ron

P.S.

Still, it’s best to consider whether and which such modifications/additions are to be made after identifying actual code where they would be helpful, rather than hypothesising that they might be. Fewer things are better than more things, and so adding things should be motivated by actual problems encountered.