Proposal for Promise.prototype.flatten
Bergi
a.d.bergi at web.de
Wed Apr 24 07:07:54 UTC 2019
Hello,
I oppose this proposal.
In my opinion, mixing normal exceptions (promise rejections) with
result-error-tuples is rather inconsistent than a more consistent
interface. The only thing it might interface better with are
node.js-style callbacks, but we already deprecated those in favour of
promises.
`if (err) throw err;` is reminiscent of this old style, it's no longer
necessary to explicitly re-throw with modern syntax.
It's not even simpler, or better to read. The example you gave could
easier be written as
```js
async function test(promise1, promise2, promise3) {
const val1 = await promise1.catch(err => void err); // ignore exceptions
const [val2, val3] = await Promise.all([promise2, promise3]); //
throw to caller
return val1 + val2 + val3;
}
```
(Notice also that no default value for the destructuring is necessary,
which is a rather error-prone part of your snippet). Using `catch`
forces the programmer into explicitly providing a default value (even if
`undefined`), which could go unnoticed otherwise.
Can you please add an example where using `.flatten()` actually
introduces an advantage?
If one needs a more powerful error handling approach, you should use
`then` with two callbacks. (Getting a try-catch-else syntax
<https://stackoverflow.com/questions/4872170/javascript-try-catch-else-finally-like-python-java-ruby-etc>
for that would be nice, though).
As already mentioned, the name `flatten` is ill-suited for this method.
If you absolutely need this functionality, use `.then(r=>[,r],e=>[e])`
in your code, or put it inside a helper function. (Or use one from a
library like <https://github.com/scopsy/await-to-js/>).
We do not need this as a method in the EcmaScript standard.
best regards,
Bergi
More information about the es-discuss
mailing list