On 10/31/19 4:26 AM, Paolo Amadini wrote:
On 10/30/2019 10:19 PM, Jan-Ivar Bruaroey wrote:
Promise.all(promises.map(p => p.catch(e => e)))
https://stackoverflow.com/questions/31424561/wait-until-all-promises-complete-even-if-some-rejected/36115549#36115549
By the way, this "catch(e => e)" call may make sense as an example in
the Stack Overflow answer (and thanks for posting it here), I just want
to point out that taken out of context it is clearly an anti-pattern.
The context here is the same as Promise.allSettled: we explicitly *do*
want to ignore errors, right?
I thought you had a great point against Promise.allSettled: it competes
with Promise.all for attention among people who don't understand the
difference, leading them to use a flame thrower instead of garden rake.
At least in my pattern, there's a `catch` prominently displayed giving a
clue errors are willfully being captured.
Unless you have guarantees about the value of "e" and the expectations
around the return value of "Promise.all", muddying the rejection and
fulfillment values together may lead to bugs that occur rarely and are
difficult to track, and potentially even security bugs.
Yes, Boris gives a proper polyfill. I'd counter that unless you're
writing some generic library, in almost any other context, the
anti-pattern to me is *not* having guarantees (or at least expectations)
around the types of r and e. That said, everything you say is true.
Rejection handling has been one of the most common mistakes I've seen
when reviewing patches (although that was a while ago when promises were
still new), so it's good to be aware of those anti-patterns.
No disagreement there. Hopefully the awkward and longer name will deter
all but those who really need it from reaching for allSettled. But yeah,
I'm in the camp that we shouldn't have added it.
Cheers!
.: Jan-Ivar :.
Cheers,
Paolo
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
