[concurrency-interest] CompletionStage.handle() with function returning CompletionStage

Chris Povirk cpovirk at google.com
Mon Feb 22 16:15:32 EST 2016

FWIW, some data from Guava:

Our Futures class used to have the opposite problem: It had *only* the
CompletionState version of exceptionally(). (In our terms, this was
FutureFallback), where FutureFallback returns a Future or throws). We found
that ~15% of users needed that power.

There's an asterisk on that "15%": While I *think* my notes mean "15% of
users need to return a Future," they might mean something else: Because we
were evaluating a switch to Function<Throwable, V>, we needed to consider
what would happen to users who threw a checked exception. It's possible
that I lumped them into the "15%" along with the users who needed to return
a Future. I probably didn't, but I can't guarantee it. And
CompletionStage.exceptionallCompose wouldn't be offering the ability to
throw a checked exception.

We ended up deciding to provide both
But it's possible that our users differ from CompletionStage's. For
example, maybe we slant more toward application developers and less toward
tool developers. Or maybe we just hate checked exceptions marginally less
than other people :)

(RE: handle(): We don't have anything like it.)

(Ideally I would have provided this information 10 days ago or, better yet,
during the review of CompletableFuture. Sorry. We didn't get around to
reviewing our method until last year.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160222/cfdad08f/attachment.html>

More information about the Concurrency-interest mailing list