最近我看到一些开发者使用这种方法来处理 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失败了,那么数组的第一项是错误,第二项是未定义。就是这样了。
他们认为这很优雅,使代码更易读。但我不这么认为,我也不建议这样使用它
我认为这样的封装有点过度,在大多数情况下,不需要这样做。接下来,我将从两个角度说明我的观点。
Async/await api的目的是允许开发者像写同步代码一样写异步代码。因此,可以使用try...catch来捕获async/await错误。
而这样的函数似乎为我们考虑到了一切,但其他刚看到你的代码的开发者总会有这样的疑问。为什么to函数返回的Promise所使用的await没有用try...catch来包装?
只有找到原始的to函数定义,并理解其意图,你才能知道 "啊,原来to函数返回的 Promise 永远不会被拒绝"。
所以它进一步增加了其他开发者的理解成本,使得熟悉的 async/await 变得不再 "熟悉"。
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
虽然大家知道async/await,但是很多人对这个方法中内部怎么执行的还不是很了解,本文是我看了一遍技术博客理解 JavaScript 的 async/await
Async实际上是一个封装了自动化执行并返回一个Promise的Generator函数的语法糖。这句话的意思我们可以分为三个部分来解读:首先它有一个自动化执行,Generator函数是依靠不停的调用.net来依次执行的,Async有一个自动化执行的过程
Node.js7.6起, Node.js 搭载了有async函数功能的V8引擎。当Node.js 8于10月31日成为LTS版本后,我们没有理由不使用async函数。接下来,我将简要介绍async函数,以及如何改变我们编写Node.js应用程序的方式。
自2015年11 发布1.7版以来,TypeScript 已支持 async/await 关键字。编译器使用 yield 将异步函数转换为生成器函数。这意味着咱们无法针对 ES3 或 ES5,因为生成器仅在 ES6 中引入的。
async/await 大家肯定都用过,在处理异步操作的时候真的是很方便。那今天主要讲一些在使用 async/await 时容易忽略和犯错的地方。上面的代码中,每一行都会 等待上一行的结果返回后才会执行。
有一个图片列表,我想要在图片onload成功之后获取加载成功的图片列表,图片资源加载为异步,我们使用ES7的async await方式实现,多张图片,是用for循环。
Async 和 Awaiit 是 Promise 的扩展,我们知道 JavaScript 是单线程的,使用 Promise 之后可以使异步操作的书写更简洁,而 Async 使 Promise 像同步操作
最近代码写着写着,我突然意识到一个问题——我们既然已经有了 Promise 和 then,为啥还需要 async 和 await?这不是脱裤子放屁吗?
如果让你手写async函数的实现,你是不是会觉得很复杂?这篇文章带你用20行搞定它的核心。经常有人说async函数是generator函数的语法糖,那么到底是怎么样一个糖呢?让我们来一层层的剥开它的糖衣。
async/await是ES7的写法,可以让非同步call back写法看起来像同步的顺序去执行。以下我们new一个Promise的class并return给一个function
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!