有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。
最近我看到一些开发者应用这种办法来解决 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) { const parsedError = 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拦截器。
所以它可能并不像预期的那样实用。也就是说，它可能只用于整个我的项目的一小部分，而且老本超过了收益。
这就是我所有的观点，你怎么看？你赞成这种做法吗？
编辑中可能存在的bug没法实时晓得，预先为了解决这些bug,花了大量的工夫进行log 调试，这边顺便给大家举荐一个好用的BUG监控工具 Fundebug。
作者：Marina Mosti 译者：前端小智 起源：medium
原文：https://blog.bitsrc.io/stop-u...
交换
文章每周继续更新，能够微信搜寻「 大迁世界 」第一工夫浏览和催更（比博客早一到两篇哟），本文 GitHub https://github.com/qq449245884/xiaozhi 曾经收录，整顿了很多我的文档，欢送Star和欠缺，大家面试能够参照考点温习，另外关注公众号，后盾回复福利，即可看到福利，你懂的。