本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一工夫和你分享前端行业趋势，学习路径等等。
更多开源作品请看 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 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。