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)))

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.


.: Jan-Ivar :.


dev-platform mailing list

Reply via email to