[External] : Re: Changes to JEP 453

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Ron Pressler" <ron.pressler at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "loom-dev" <loom-dev at openjdk.org>
> Sent: Wednesday, May 24, 2023 2:48:45 PM
> Subject: Re: [External] : Re: Changes to JEP 453

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

yes, no inference because the Java type system lacks unions.
But i see the explicit declaration of the common exception has an advantage more than a burden, you care once about the type of the exception and the STS implementation deals with the exceptions properly, the same way the type of the result is correctly propagated.

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

:)
And as i said earlier, there is a trick to avoid InterruptedException to be part of the inferred exceptions.

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

I agree with your last sentence, calling methods on callables that have not be run or have been interrupted by shutdown() is an issue because the state() of those tasks give you enough information. But i disagree with the first part of your paragraph, exception logging can not be handled de-centrally (inside the Callable) because you may log exceptions that are due to the call to shutdown(), so exceptions which should not be logged because they are part of the normal lifecycle of a STS.

I believe that in that case, the future subclass of STS with a join() that takes a function with a stream is the way to handle centralized logging because only the result|exception of the tasks that have get outside of handleComplete() will be seen by the stream.

> 
> — Ron

Rémi