[External] : Re: Future.resultNow / exceptionNow

[Ron Pressler]

> On 21 Nov 2021, at 14:00, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
> 
> No, you don't know what went wrong. You only know something did.

The methods must only be called when the Future is in a certain state, and the exception tells you exactly what the actual, unexpected state is. You have all the information you could ever need to fix the bug. Suppose you call resultNow without having called join first. The error you’ll get will tell you exactly that this is the bug, and that adding join is necessary. And suppose you call resultNow after join but before handling exception, the error you’ll get will tell you exactly that that’s what missing.

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

The exception tells you *which* incorrect state has led to the problem (maybe the message should include precisely which State enum value is expected and which is found).

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

The problem that resultNow was created to solve is that in the common case, in which you already know the state of the future and have already handled exceptions, anything other than returning the result would be an unnecessary complication. Write down that code and see for yourself.

> 
> 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 don’t understand. The method for state introspection, Future.state, never fails. resultNow, which is *not* for state introspection, never punishes you. It just cannot continue when a bug in your program makes its precondition false, and it helps you by telling you what your bug is.

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

The purpose of resultNow is not to be a non-blocking get (although you could write a non-blocking get with a combination of state and resultNow). The purpose of resultNow is to obtain the result in the common case, in which you already know that it’s there, and are *guaranteed* that the method will never fail.

> Reminds me of NIO Selector API, where almost anything can result in a bunch of Runtime Exceptions.

If we could panic, maybe we’d panic. The exception is not the point. It just indicates a bug in the program.

I understand that you’d like a somewhat different feature, but please start with a motivation: take the current API and show what *problem you run into* that you’d like to solve.

If your problem is unrelated to the JEP but is just about a non-blocking polling mechanism for Future, I’d still argue that having both state and resultNow is superior to a single maybeGetResult, because the former is more general: you can use it just as efficiently for polling or for obtaining the result in cases where the correct state is guaranteed.

— Ron