Future.resultNow()

[Alex Otenko]

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.

Alex

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