[External] : Re: Future.resultNow / exceptionNow

[Ron Pressler]

> On 21 Nov 2021, at 15:57, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
> 
> 
> Sure. Here it is:
> 
> exe.join();
> Throwable th = future.exceptionNow();
> if (th != null) throw rewrap(th);
> // here resultNow is guaranteed to be ok
> // but exceptionNow will throw
> 

I am not sure what you’re showing there. That code is obviously incorrect — it asserts something that isn’t true -- and the error will tell you why. If you want to do a check, why do you insist on using a method specifically designed to do something else rather than use the new method intended for that purpose? If you want to poll the state, do:

If (future.state() == State.FAILED) throw rewrap(future.exceptionNow());

> 
> People will use it as a get() that doesn't require try-catch.

resultNow can only be used in a state where it is the right thing to do.

> 
> Well, and my contention is that you declare it a bug. What's the horrible sin of the above check? A throwing exceptionNow doesn't really save me from anything.

The sin is the same one as in calling Lock.unlock without holding the lock. resultNow is a method that says: I know that this future has a result, so give it to me. If you do "I know that this future has a result so give it to me” but it doesn’t have a result, then you’re using this operation incorrectly. 

We’ve added a method that allows you to do what you want. Why do you want to do that thing not with the method we’ve added for that purpose but with the method we’ve added for a different purpose?

— Ron