<div dir="auto">I think that generally the fact that the interfaces of j.u.function are built without proper exception parameter pushes the problem, and that a more complete solution is to maybe create j.u.f.exceptionally that contains the "correct" implementations.<div dir="auto"><div dir="auto"><br></div><div dir="auto">This exact same problem was discussed when talking about ScopedValues, and it appears in a lot of place outside of loom as well and as long as there is no way to handle exceptions correctly in lambda provided by the standard library, more and more people will get "hurt" by it</div><div dir="auto"><br></div><div dir="auto">By "correct" implementation I am talking about e.g.</div><div dir="auto"><br></div><div dir="auto">package java.util.function.exceptionally;</div><div dir="auto"><br></div><div dir="auto">@FunctionalInterface</div><div dir="auto">public interface Predicate<T, E extends Throwable> {</div><div dir="auto">    boolean test(T t) throws E;</div><div dir="auto">    \\ ...defaults and statics </div><div dir="auto">}</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 14, 2023, 17:43 Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Original Message -----<br>
> From: "Alan Bateman" <<a href="mailto:Alan.Bateman@oracle.com" target="_blank" rel="noreferrer">Alan.Bateman@oracle.com</a>><br>
> To: "attila kelemen85" <<a href="mailto:attila.kelemen85@gmail.com" target="_blank" rel="noreferrer">attila.kelemen85@gmail.com</a>><br>
> Cc: "loom-dev" <<a href="mailto:loom-dev@openjdk.org" target="_blank" rel="noreferrer">loom-dev@openjdk.org</a>><br>
> Sent: Sunday, May 14, 2023 3:14:30 PM<br>
> Subject: Re: STS allows to bypass any checked exceptions<br>
<br>
> On 14/05/2023 11:47, Attila Kelemen wrote:<br>
>> :<br>
>> That is - assuming join is invoked without interruption - my problem<br>
>> with the shown behaviour is that the exception thrown by the<br>
>> `Callable` is discarded and an ISE is thrown instead, so we are losing<br>
>> the original exception which could be used for tracking the issue.<br>
> <br>
> The `get` method is used to get the result of as task that completed<br>
> successfully, it's not discarding anything. But maybe you are arguing to<br>
> stay with Future so that Future::get throws ExecutionException with the<br>
> exception as the cause?<br>
<br>
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.<br>
<br>
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.<br>
<br>
I think the typ of the exception should be tracked by the type system, what I've called "exception transparency" in a previous mail,<br>
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.<br>
<br>
By seeing TaskHandle as a Supplier, we are pushing users to ignore exceptions thrown by the callable.<br>
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.<br>
<br>
> <br>
> -Alan.<br>
<br>
Rémi<br>
</blockquote></div>