[External] : Re: Future.resultNow / exceptionNow

[Alex Otenko]

No, you don't know what went wrong. You only know something did.

So, you see the code is broken. You get to deploy two patches: one to start
using a different method to observe what has lead to the problem (likely a
Runtime Exception or Error - say, NPE in the task), then the fix for the
actual problem.

As for maybeResultNow - I haven't warmed up to the idea that throwing by
resultNow is saving me from a really bad problem.

I am looking at the code that joined on executor, and don't see why it is
more correct for (albeit indirect) state introspection to punish me with
hidden throws. I am looking at another example that polls for result, and
again don't see why throwing is better for something that is like a
non-blocking get. Reminds me of NIO Selector API, where almost anything can
result in a bunch of Runtime Exceptions.

Alex

On Sun, 21 Nov 2021, 12:51 Ron Pressler, <ron.pressler at oracle.com> wrote:

> 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> 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> wrote:
>
>>
>>
>> > On 21 Nov 2021, at 11:32, Ron Pressler <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.
>
>
>