Future.resultNow()

[Alex Otenko]

What is the bug in this case? The exception thrown by the task, the caller
not checking the task is done, or that it is done with an exception?

The API owners seem to disagree with me, but I don't think any of those is
a bug. I polled the task - I got no result now, I moved on. Especially
since a get() would already do the right thing, including throwing the
exception, a non-blocking method feels like it should be more like
BlockingQueue.poll compared to BlockingQueue.take.

Alex

On Sat, 20 Nov 2021, 21:57 , <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Alex Otenko" <oleksandr.otenko at gmail.com>
> *To: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"loom-dev" <loom-dev at openjdk.java.net>
> *Sent: *Samedi 20 Novembre 2021 22:49:01
> *Subject: *Re: Future.resultNow()
>
> No, I am not afraid :)
>
> I just think introspecting the chain of causes is brittle - in the sense
> that it relies on a specific implementation wrapping the exception in a
> particular way.
>
>
> As Brian said, IllegalStateException is not an exception you should ever
> catch like NPE or AIOOBE, it's equivalent to a
> ReadTheFuckingManualException,
> it's an error raised because the developer has misunderstood how the API
> works, so providing the cause (maybe as an error message) helps to fix the
> bug.
>
>
> Alex
>
>
> Rémi
>
>
> On Sat, 20 Nov 2021, 21:44 , <forax at univ-mlv.fr> wrote:
>
>>
>>
>> ------------------------------
>>
>> *From: *"Alex Otenko" <oleksandr.otenko at gmail.com>
>> *To: *"Remi Forax" <forax at univ-mlv.fr>
>> *Cc: *"loom-dev" <loom-dev at openjdk.java.net>
>> *Sent: *Samedi 20 Novembre 2021 21:10:59
>> *Subject: *Re: Future.resultNow()
>>
>> I wouldn't expect it to contain the exact cause (why the cause, and not
>> the cause of the cause of the cause), and expect exceptionNow to be the
>> source of truth.
>>
>>
>> Are you afraid that people will catch the ISE to extract the exception
>> instead of using Future.get() and catch the ExecutionException to extract
>> the exception ?
>> This is a valid concern, ExecutionException is checked and ISE is not, if
>> you provide two ways to get the same thing, i believe people will go with
>> the method that throws an unchecked exception.
>>
>> So perhaps, instead of using the cause field, the error message of the
>> ISE should contain a string version of the exception like toString() does.
>>
>>
>> Alex
>>
>>
>> Rémi
>>
>>
>> On Sat, 20 Nov 2021, 19:14 Remi Forax, <forax at univ-mlv.fr> wrote:
>>
>>> If a callable throws an exception, Future.resultNow() throws an ISE but
>>> forget to set the resulting exception as the cause of the ISE.
>>>
>>> regards,
>>> Rémi
>>>
>>
>