Settle on an interface for Futures.allAsList/successfulAsList (and Google-internal allAsMap/successfulAsMap)

[gissuebot]

Original issue created by [email protected] on 2013-08-29 at 09:11 PM

---

1. Are there better names? (Do they deserve the same name with disambiguating parameters? Do they at least deserve names that are near one another alphabetically?) Here's an internal-only doc with some discussion: https://docs.google.com/a/google.com/document/d/1Ry0Jx0tIJ8zFX9TnH6dbVCRGlYwrlkyiyekSYnay1VA/edit ("Possible rename of bulk Future methods")
2. Would successfulAsList be better if it returned a list containing only the successes rather than a list containing interleaves successes and nulls? (Previously, people might have wanted to match up indexes (though IIRC my survey showed that few if any users were doing this). Nowadays, they can use successfulAsMap [edit: oops, currently Google-internal], which makes it easier to associate values with keys (which is probably more natural than associating them with indexes, anyway.) (Less plausible advantage: A user might really want to distinguish between "returned null" and "failed." This would let him do that, as the "failed" entries would go away.) Another option is to add a third method with the failures stripped, but I doubt we'd want to bother.
3. When an allAsList input fails, should we cancel the other inputs? Should this be configurable? Here's an internal-only thread with some discussion: https://groups.google.com/a/google.com/d/topic/java-users/9utRs2xAafk/discussion

[edit: see also #3394 about a Collector-based equivalent]

[gissuebot]

Original comment posted by [email protected] on 2014-08-13 at 01:49 PM

---

An internal user would like to be able to access the result as a Future<ImmutableList<V>> rather than a Future<PlainListThatHappensToBeImpossibleToMutate<V>>. He's using a framework that requires known immutable objects. He can transform(), of course, but if we make change (2), this would be an opportunity to switch to ImmutableList (at the cost of some verbosity to users who don't care).

An additional feature to consider is some kind of configuration of logging (or, more generally, of handling of failures). Our current policy can be a bit spammy, but we would fear dropping important messages if we turned logging off universally.

This still doesn't make the API clear. Future<ImmutableList<Foo>> f = Futures.collect(list).allMustSucceed(), etc.? There are many options.

[cpovirk]

We introduced Futures.{whenAllSucceed,whenAllComplete},{call,callAsync}. But we haven't addressed the List case, cancellation, or logging configuration.

[cpovirk]

Hacky workaround: Ensure that every failure exception thrown is equals() to every other failure exception. You may be able to accomplish that if you control the exception type that's thrown, or you can using Futures.catching() to effectively replace any failure with a custom exception.

[cpovirk]

See also "SEVERE: input future failed" spams stdout/stderr (#2134), in which I propose a possible workaround for people with that problem.

[kluever]

This is now fixed.

[cpovirk]

(Oops, I forgot about the logging business. Still, I'm not sure that the @Beta-ness of the API would make much practical difference in how disruptive such a change would be.)

I'm going to reopen this issue to track the theoretical possibility that we'd (a) introduce a better API for this (whenAllComplete().collectSuccessful() or whatever) and (b) introduce a Map version publicly.