STS allows to bypass any checked exceptions

Attila Kelemen attila.kelemen85 at gmail.com
Sun May 14 17:51:00 UTC 2023


Holo The Sage Wolf <holo3146 at gmail.com> ezt írta (időpont: 2023. máj.
14., V, 19:38):
>
> 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
>

Sorry, for being confusing. I meant that what you wrote is basically
the only way, if the `TaskHandle` itself is not passed around (of
course you can always create something very similar to `TaskHandle`
instead, but that would be without any purpose). This is because it is
not possible to create a common base type `sealed interface Result`,
because then, if `Result` is non-generic, then you will force an
unsafe cast (as far as the compiler can tell) on the `Success`
implementation of `Result. If `Result` is generic, then you are
forcing an unused generic parameter on the `Failure` implementation of
`Result`, which is awkward.

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

Yes, it is technically possible, but my point was that it would be
quite awkward, given that `Callable` instances are prone to being
wrapped. In fact - I believe - if function types were a thing in Java,
then `fork` would expect one, where it would be (probably) really
impossible. Which makes relying on the fact that you can have a known
implementing class (or extending interface) of `Callable` a little
dubious.


More information about the loom-dev mailing list