[External] : Re: Changes to JEP 453

[Ron Pressler]

> On 24 May 2023, at 13:14, forax at univ-mlv.fr wrote:
> 
> the idea is to declare explicitly the exception when creating the STS because Java is not able to do the union of several exceptions,
> but the compiler has no problem to infer the type of the exception (which is a subclass of the one declared when creating the STS) when calling fork.


Even if we did have unions of multiple forks, what I tried saying was that we could have exception transparency for Subtask.result, but not for SoF.throwIfFailed, which is what we want to encourage people to use. There could be no inference there.

> 
> Handling developer mistakes at compile time, not at runtime is better IMO.
> This is important in this particular case because exception paths in the code tend to be less tested.

Ok, so what you’re saying is: It may be desirable to have STS bound the exception types thrown by the forks (though that’s not exception transparency). I can see that, and we tried that in one of the prototypes but weren’t sure about whether having two type parameters (or one for SoF) may deter users; that’s not helped by the fact that tasks may frequently throw both IOException and InterruptedException whose common supertype is Exception. But I think that's a reasonable tweak to consider in the future.


BTW, I just noticed something you said about logging in your previous message. STS is designed for a style where exceptions are handled centrally and logging is not handled centrally, i.e. where the scope is interested in everything that could affect its own outcome and in nothing but what could affect its own outcome. I’m not saying that other styles wouldn’t be better sometimes, but STS is designed for that particular style. So if you find yourself ever inspecting results that don’t affect the outcome or explicitly handling a particular fork’s exceptions — i.e. if you find yourself ever calling any Subtask method other than get outside handleComplete — then there’s a very good chance you’re not using STS in the intended manner.

— Ron