STS allows to bypass any checked exceptions

[Holo The Sage Wolf]

don’t think there would be even an easy way around this, because you
can’t reasonably create a common base type for the two results

I don’t think I understand your point, STS receives the parameter of the
return type, so you can do STS#handleSuccess(T result, ...).
And similarly, you don’t have a parameter for the exception type so you
can’t do this for STS#handleFailure

why the Callable is being passed around

It can, by using type-checks in some custom STS implementation, but I agree
that it shouldn’t be the normal behavior.

On Sun, May 14, 2023 at 8:22 PM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> > If we are already on the subject, as you stated, STS#handleComplete has
> only 2 possible states, success and failure, so why not completely separate
> them:
> >
> > STS#handleSuccess(T result, Callable task [, boolean cancelled])
> > STS#handleFailure(Throwable exception, Callable task [, boolean
> cancelled]) (note that we can’t use parameterize exception here)
> >
>
> I don't think there would be even an easy way around this, because you
> can't reasonably create a common base type for the two results
> (previously - as Rémi said - I thought sealed interfaces would be
> solution, but that is impossible due to the generic parameter), unless
> you pass the `TaskHandle` where you could call the appropriate method
> based on the state.
>
> Also, I'm not even sure why the `Callable` is being passed around
> here. What is STS supposed to do with that? It can't really use it as
> an ID, because you might be running the same `Callable` instance
> multiple times. Also, passing it just makes you nervous wrapping it
> (which you might be forced to do in some cases). If a feature of being
> able to distinguish between tasks is needed, then `fork` should allow
> associating an additional custom object with the submitted `Callable`.
> But - to me - it seems that is going too far with STS.
>


-- 
Holo The Wise Wolf Of Yoitsu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230514/3eae56b2/attachment.htm>