STS allows to bypass any checked exceptions

[Remi Forax]

----- Original Message -----
> From: "Alan Bateman" <Alan.Bateman at oracle.com>
> To: "attila kelemen85" <attila.kelemen85 at gmail.com>
> Cc: "loom-dev" <loom-dev at openjdk.org>
> Sent: Sunday, May 14, 2023 3:14:30 PM
> Subject: Re: STS allows to bypass any checked exceptions

> On 14/05/2023 11:47, Attila Kelemen wrote:
>> :
>> That is - assuming join is invoked without interruption - my problem
>> with the shown behaviour is that the exception thrown by the
>> `Callable` is discarded and an ISE is thrown instead, so we are losing
>> the original exception which could be used for tracking the issue.
> 
> The `get` method is used to get the result of as task that completed
> successfully, it's not discarding anything. But maybe you are arguing to
> stay with Future so that Future::get throws ExecutionException with the
> exception as the cause?

As Attila said, the API of TaskHandle makes it too easy to discard the exception, and and if the exception rarely happens it will be unnecessary hard to debug.

I think that TaskHandle.get() throwing ISE if STS.join() is not called before is fine because it's a reproducible scenario, throwing ISE if an exception appears in the callable is not fine because it depends on an external factor.

I think the typ of the exception should be tracked by the type system, what I've called "exception transparency" in a previous mail,
mainly it means that get() should return the value or throw the exception, the type of the exception, like the type of the value should be a type variable.

By seeing TaskHandle as a Supplier, we are pushing users to ignore exceptions thrown by the callable.
I would prefer taskHandle::get to be convertible to a Supplier only if the callable does not throw an Exception, otherwise taskHandle::get should be convertible to a Callable.

> 
> -Alan.

Rémi