Thinking--异步请求函数return应不应该加await?
Posted 奋飛
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Thinking--异步请求函数return应不应该加await?相关的知识,希望对你有一定的参考价值。
Thinking系列,旨在利用10分钟的时间传达一种可落地的编程思想或解决方案。
在 codereview 代码中,发现了这样的两种写法。
写法一:
async function fn () {
return await someAsyncReq()
}
写法二:
function fn () {
return someAsyncReq()
}
有哪些区别呢?从写法上,直观可以看到的是
- 写法一:返回的是执行结果(异步执行过程在 fn 函数内部)
- 写法二:返回的是 Promise(异步执行过程在**调用 fn **函数的方法)
我们知道,调用 async 包裹的函数也需要通过 async...await
进行处理;同样的获取异步结果,也可以通过 async...await
处理,那么上述调用方式一直:
await fn()
从这个层面看,貌似我们可以忽略具体返回是 retrun promise
还是 return await promise
。这个结论,在一定场景下的确没有问题 – 异步函数没有异常抛出
/*写法一:示例*/
async function fn1 () {
return await new Promise(reslove => setTimeout(() => reslove('ligang'), 1000))
}
/*写法二:示例*/
function fn2 () {
return new Promise(reslove => setTimeout(() => reslove('ligang'), 1000))
}
await fn1()
await fn2()
上述执行结果一致,都会在 1000ms 后返回 “ligang”。
那么什么场景下,上述两种写法会有差异呢?
写法一:
async function fn () {
try {
return await someAsyncReq()
} catch (err) {
return await Promise.rejct('异步操作发生错误')
}
}
写法二:
function fn () {
try {
return someAsyncReq()
} catch (err) {
return Promise.rejct('异步操作发生错误')
}
}
当异步操作发生异常时,会有差异:
- 写法一:会返回异常信息,即执行 catch 部分
- 写法二:异常的捕获需要在调用的函数中处理,fn 函数中 catch 部分无法执行
如果仔细分析,相信大家可以得出相应的结论。
function promisedDivision(n1, n2) {
if (n2 === 0) {
return Promise.reject(new Error('Cannot divide by 0'))
}
return Promise.resolve(n1 / n2)
}
/*写法一:示例*/
async function fn1 () {
try {
return await promisedDivision(6, 0)
} catch (err) {
return err
}
}
/*写法二:示例*/
function fn2 () {
try {
return promisedDivision(6, 0)
} catch (err) {
return err
}
}
await fn1() // Error: Cannot divide by 0
await fn2() // Uncaught Error: Cannot divide by 0
对于方式一,reject 的错误被成功捕获;对于方式二,reject 的错误被直接抛出了(Uncaught)。对于异常的处理,是提升代码鲁棒性的重要途径之一。且对错误未捕获,会导致程序终止执行。
结论
-
如果当前场景,需要我们对错误统一处理,建议使用写法一
return await someAsyncReq()
,在函数内部统一处理 -
如果当前场景,需要我们对错误差异化处理,建议使用写法二
return someAsyncReq()
,调用者可差异化处理
// return await promise
aysnc function _request(options) {
try {
return await axios(options)
} catch (err) {
let errorMsg = '请求发生了错误'
if (err.code === 'ECONNABORTED') {
errorMsg = '请求超时!'
} else if (axios.isCancel(err)) {
errorMsg = '请求被取消!'
} else {
switch (err.response.status) {
case 401: // token失效
case 403: // 无权限访问
case 404: // 接口不存在
case 500: // 接口错误
}
}
return await Promse.reject({
errorCode: err.response.status,
message: `${errorMsg}:${err}`
})
}
}
// return promise
async function request (options) {
return new Promise((resolve, reject) => {
try {
const {status, content} = _request(options)
if (status === 'success'){
resolve(content)
} else {
reject({
errorCode: status,
message: content
})
}
} catch (err) {
reject(err)
}
})
}
项目中对 axios 请求经常会按照上述原则进行封装,axios 请求我们直接 return await promise
处理,便于对统一错误进行通用性处理(如401、403、500等),一致性强,减少不必要的冗余代码;而对于业务端我们采用 return promise
处理,如 status !== 'success'
情况,将错误抛出由调用者根据业务情况进行差异化处理,灵活度更高,更能契合业务需求。
以上是关于Thinking--异步请求函数return应不应该加await?的主要内容,如果未能解决你的问题,请参考以下文章