CompletionStage.handle() with function returning CompletionStage

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

CompletionStage.handle() with function returning CompletionStage

Petter Måhlén
Hi,

One thing that I and my colleagues have felt is missing in CompletionStage is a version of handle() (and exceptionally()) taking a function that returns a CompletionStage<U> (or T) instead of a plain U. This is particularly useful when doing things like fallbacks or retries for remote service calls.

We've implemented those methods ourselves, calling them 'handleCompose' and 'exceptionallyCompose': https://github.com/spotify/futures-extra/blob/master/src/main/java/com/spotify/futures/CompletableFuturesExtra.java#L110, but of course using a static method like that reads less well than the normal fluent API.

What is the rationale for not including those versions?

/ Petter

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: CompletionStage.handle() with function returning CompletionStage

Doug Lea
On 02/12/2016 03:36 AM, Petter Måhlén wrote:
> Hi,
>
> One thing that I and my colleagues have felt is missing in CompletionStage is a
> version of handle() (and exceptionally()) taking a function that returns a
> CompletionStage<U> (or T) instead of a plain U. This is particularly useful when
> doing things like fallbacks or retries for remote service calls.

> We've implemented those methods ourselves, calling them 'handleCompose' and
> 'exceptionallyCompose':
> https://github.com/spotify/futures-extra/blob/master/src/main/java/com/spotify/futures/CompletableFuturesExtra.java#L110,
> but of course using a static method like that reads less well than the normal
> fluent API.
>
> What is the rationale for not including those versions?
>

I can see how this would be useful in some styles of programming using
CompletionStages. But when coming up with the APIs, no one predicted
this style might become common, so no one made a case for including it
in the main CompletionStage interface.

I was thinking that by letting this post sit a while, others might
try to make this case. But not yet.

-Doug



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: CompletionStage.handle() with function returning CompletionStage

Chris Povirk
In reply to this post by Petter Måhlén
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 withFallback(..., 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.)

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: CompletionStage.handle() with function returning CompletionStage

Petter Måhlén
Not much activity on this thread - I'm not sure what conclusions to draw from that. We did find a need for these versions inhouse at Spotify, and apparently also in Google, though unlike us, they have numbers to quantify their need. :)

We'll keep using our static versions. If it turns out that fluent analogues appear in some future version of CompletionStage, that would be great for us.

On Mon, 22 Feb 2016 at 22:15 Chris Povirk <[hidden email]> wrote:
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 withFallback(..., 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.)

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest