Future.resultNow / exceptionNow

[Paul Bjorkstrand]

>
>
> >
> > Suggestions:
> > 1. Add another built-in "handler" that is similar to ShutdownOnFailure,
> but
> > only tracks the first failure, and does not shut down the executor. This
> is
> > for cases when you want everything to try to complete, but want to report
> > an error that occurred.
>
> Can you give a concrete example of when you’d want that?
>

I don't have any for that specific case, but a similar case: allowing all
to complete and reporting all exceptions (via some AggregateException that
contains more than one "cause"):

In the past I built a metrics-tracking system that reported data to
multiple remote APIs. While it was not good if something failed, it wasn't
mission critical if one or two failed from time to time, while the rest
succeeded. Even though we didn't care that things failed, in terms that the
application could continue running, we did need to know what those
failures were so we could identify and troubleshoot the errors. In this
case, we didn't care about the responses, but only cared about the errors,
for logging.

Thinking about it, it would be relatively simple to filter down the list of
futures to those ones that completed exceptionally, but having some way to
do it that didn't require a lambda with an == test in it would be
convenient. Even static util methods like Future.State.isXxx, for each of
the states would be helpful, so you can use State::isXxx instead of the
lambda. I completely understand if we want to wait on that kind of addition
until more is learned from the preview.

I wish I had some project in my back pocket that I could use to test out
Structured Concurrency more, but my tinkerings have me interested in
learning where else it can be useful. I look forward to seeing how some of
the Loom subprojects come together, specifically Scope Locals & Structured
Concurrency. Great work so far!

-Paul