STS allows to bypass any checked exceptions

[Holo The Sage Wolf]

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.

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

By "correct" implementation I am talking about e.g.

package java.util.function.exceptionally;

@FunctionalInterface
public interface Predicate<T, E extends Throwable> {
    boolean test(T t) throws E;
    \\ ...defaults and statics
}

On Sun, May 14, 2023, 17:43 Remi Forax <forax at univ-mlv.fr> wrote:

> ----- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230514/be51949c/attachment.htm>