[External] : Re: Changes to JEP 453

[Ron Pressler]

> On 24 May 2023, at 10:31, forax at univ-mlv.fr wrote:
> 
> 
> Here we are discussing about two things, the first one is to have a method result() in Subtask, the second is exception transparency, i think even if you no not want a method result() in Subtask (let see how people use the preview), having exception transparency also simplify the code.

What you’re describing isn’t really exception transparency (to me, exception transparency means “I throw what this thing throws”, and so implies some kind of inference, which we could do in the result case but for the time being we want to encourage people to handle exceptions centrally). Even supposing we had a language feature that could allow specifying multiple exception types, e.g. `new StructuredTaskScope.ShutdownOnFailure<ExceptionA | ExceptionB>` you'd still have to declare all of the forks’ exception types in advance, because we fork different tasks in different calls to fork and we still couldn’t infer exception types to make them transparent.

As a result, the code is only simplified by the removal of `catch (Throwable e) { throw new RuntimeException(e); }`. It isn’t much of a simplification, and it’s also not what we want, because runtime exceptions will also be propagated without a good stack trace, and that’s probably what few want. 

Defining a method:

    static <T extends Exception> Function<Throwable, T> propagate(Class<T> ext) {
        return e -> {
            if (ext.isInstance(e)) return ext.cast(e);
            if (e instanceof Error err) throw err;
            else throw new RuntimeException(e);
        };
    }

And then using it like so, `scope.join().throwIfFailed(propagate(ApplicationException.class))`, will be just as simple of not more so, as we won’t have to specify an exception type argument if we don’t want to. If that’s useful (and I say “if", because you are giving up on a good stack trace), we could fold that functionality into another overload of throwIfFailed.

— Ron