前段时间我看见许多开发人员采用此种方式来处理 async/await 错误。
/** * @param { Promise } promise * @param { Object= } errorExt– Additional Information you can pass to the err object *@return { Promise } */ function to(promise, errorExt) { return promise .then((data) => [null, data]) .catch((err) => { if (errorExt) { constparsedError =Object.assign({}, err, errorExt); return [parsedError, undefined]; } return [err, undefined]; }); }async function doSomething() { const [error1, result1] = await to(fetch()); if (error1) { return; } const [error2, result2] = await to(fetch(result1)); if (error2) { return; } // … }正如你所看见的，他们把函数包起来，把原来的Promise转换成一个肯定会成功的 “Promise”，并返回一个数组。
如果原始的Promise成功了，那么数组中的第一项是空的，表示没有错误，第二项是原始 Promise的结果。如果原来的Promise失败了，那么数组的第一项是错误，第二项是未定义。就是这种了。
他们认为这很优雅，使代码更易读。但我不这么认为，我也不建议这种采用它
我认为这种的封装有点过度，在大多数情况下，不需要这种做。接下来，我将从两个角度说明我的观点。
1. 从设计的角度来看
Async/await API的目的是允许开发人员像写同步代码一样写异步代码。因此，可以采用try…catch来捕获async/await错误。
而这种的函数似乎为我们考虑到了一切，但其他刚看见你的代码的开发人员总会有这种的疑问。为什么to函数返回的Promise所采用的await没有用try…catch来包装？
只有找到原始的to函数定义，并理解其意图，你才能知道 “啊，原来to函数返回的 Promise 永远不会被拒绝”。
所以它进一步增加了其他开发人员的理解成本，使得熟悉的 async/await 变得不再 “熟悉”。
2. 从实用性的角度来看
to函数的主要采用情况是，在同一上下文中有多个await promises，而它们相应的错误处理方式是不同的。那么就采用这个封装函数对每个错误进行不同的处理，减少对try…catch的使用。
但在实际开发，在每个到函数之后，你需要采用if语句来确定是否有错误。这与采用try…catch的本意没有什么不同，都是为了检查错误。
其次，在真实的生产环境中，下一个Promise依赖上一个Promise的情况并不少见。但重要的一点是，这两个Promise通常是关联函数。所以在外层采用try…catch来统一奈镇是没有问题的。比如说
最后，在JavaScript中，大多数Promise场景都是在Input/output上，比如网络IO和文件IO。这些IO场景可以将拦截器封装在下层，并根据错误代码统一处理。例如，采用axios拦截器。
所以它可能并不像预期的那样实用。也就是说，它可能只用于整个项目的一小部分，而且成本超过了收益。
这就是我所有的观点，你怎么看？你赞成此种做法吗？
https://blog.bitsrc.io/stop-using-async-await-like-this-use-the-original-instead-172b5df17589
