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?的主要内容,如果未能解决你的问题,请参考以下文章

到底应不应该买保险?

作为管理者,应不应该认错?

好马应不应该吃回头草?

我们究竟应不应该使用框架? [转]

程序员应不应该搞全栈

应不应该使用inline-block代替float