Loom Evades Exception Handling

[Eric Kolotyluk]

My main concern with this experiment was trying to diagnose what was going
on from the stack traces. In the end, the problem was not at all what I
could have imagined, but apparently easy for @Remi Forax <forax at univ-mlv.fr>
to see. So, it would be great if the diagnostics could be improved to help
people like me see and understand the problem earlier.

Diagnostics are not seat belts, and in this case, I am not sure what seat
belts would look like. One thing I know after using Gradle, is that bad
diagnostics can send you on a wild goose chase, so inadequate diagnostics
are preferred over bad diagnostics.

>From Structured Concurrency
<https://bugs.openjdk.java.net/browse/JDK-8277129>, the example

<T> List<T> runAll(List<Callable<T>> tasks) throws Throwable {
    try (var s = StructuredExecutor.open()) {
        var handler = new StructuredExecutor.ShutdownOnFailure();
        List<Future<T>> futures = tasks.map(t -> s.fork(t, handler)).toList();

        s.join();
        handler.throwIfFailed(e -> e); // propagate exception as-is

        return futures.map(Future::resultNow).toList();
    }
}

Is sort of what I want to do, but as far as I can tell, that example won't
compile because "tasks.map()" is not allowed, you need to use "
tasks.stream.map()". If I could apply the usual monadic operations to Java
collections, in a non-lazy way like Kotlin and Scala, I would not have
fallen into this trap, but it's unrealistic to believe that Java
collections will change to make me happy.

Note: someone should correct the examples on this page...

The beauty of this example is that it is really expressive in terms of
functional programming, which is why "Future::resultNow" is so useful, and
definitely the direction we should be going in.

Cheers, Eric




On Thu, Nov 25, 2021 at 11:53 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 25/11/2021 22:25, forax at univ-mlv.fr wrote:
> > :
> > For Alan or Ron, fork() should throw an exception if called after join()
> ?
> It's good to look at examples like this. On first glance then it may be
> trying to be a bit too clever, or maybe lazy execution is just subtle
> sometimes.
>
> The API could be changed so that join is "joinAndShutdown" but it is
> already a very limited API. There will be cases where someone will want
> to catch InterruptedException and continue after join. There will be
> other cases where jounUntil will be used to stagger forks. A more
> limited check would be detecting that join has been called without fork
> but there again, there will be cases where an exception would be
> annoying. So I think we'll need to mull on this a bit to see if further
> seat belts would be help or hindrance.
>
> -Alan
>