On 20/10/2025 19:03, Josiah Noel wrote
I assume there are good reasons to not make it like
CompletableFuture's unchecked join method, so if nothing can be done
I'll just leave it at that.
CF::join is not interruptible and will wait indefinitely when
interrupted. That may be okay in a top-level usage but would be
problematic if executed in a subtask when the scope is cancelled (as the
scope owner would block indefinitely in close waiting for the subtask).
An uninterruptible-join can be built on an interruptible-join of course
and that may be an option for a usage that you know will never be cancelled.
The application itself is nothing but an orchestration api where we
make downstream calls to other services to get and combine data. I
didn't test anything other than the default joiner because if any of
the calls fail we want to terminate the request immediately (they were
also all different types). I didn't need to check the state of the
individual tasks, so I used a supplier for the wrapper.
This is useful on two points. One is that the default policy that we
think is right for a high percentage of cases. The second is whether it
will be more common to fork subtasks that return results of the same
type or different types. So your comments are very useful, as is your
"works for me" comment in the introduction - thank you for taking the
time to send mail on your experiences.
-Alan
