问题

在进行业务开发的时候,前后端会对接口的数据结构进行约定,若接口有异常,需要将异常信息展示给用户知晓。这个流程里,数据结构是确定的(事先约定),数据的处理逻辑是相同的(展示给用户),如果在业务代码代码中重复的catch(e) { 展示给用户 },就非常的不优雅。本着Don't repeat myself(懒)的原则,需要对接口错误进行统一处理。

接下来,我会结合具体的业务场景,讲一讲我的解决方案。

业务场景

  1. 后端通过http状态标识接口状态,错误信息在response的data里
  2. 前端的处理逻辑是使用element-ui的Message展示错误信息
  3. 使用axios

axios可以通过拦截器,在业务代码处理响应之前对响应进行处理,类似于下面的流程

someAPI()
  .then(interceptorsFn)
  .then(业务逻辑)

所以,我们可以在interceptors对响应进行统一处理:

request.interceptors.response.use(
  (response) => response.data,
  (error) => {
    // 针对特定的http状态码进行处理
    if (error.response && error.response.status === 401) {
      router.push({ name: 'ssoLogin' })
      return new Promise(() => {}) // pending的promise,中止promise链
    }

    .....

    const msg = error.response.data
    Message.error(msg)

    return Promise.reject(error.response)
  }
)

如何进行特定的错误处理

不难看出,上面的方案有一个问题,如果有某个接口需要有业务代码来展示定制的错误信息(这个情况十分常见),如何处理?

naive方案1:业务代码使用其它的方式展示信息:例如Notify。
这个方案被我司产品痛骂,因为破坏了统一的错误信息展示,并且此时统一的错误信息是一个垃圾信息,没必要展示。

naive方案2:业务代码直接使用Message,顶掉统一的错误信息。
这个方案还是被产品大哥(dog)怼了,因为明显的用户体验不好,错误信息出现了闪烁。

帅气的解决方案3:业务代码决定是否隐藏统一错误提示
那么问题来了,由于是先走拦截器,再走业务代码,如何由业务代码决定是否隐藏统一错误提示呢?

我的办法是,将统一的错误提示使用setTimeout放到下一个loop执行,并通过一个变量标识是否要执行统一错误提示。

request.interceptors.response.use(
  (response) => response.data,
  (error) => {
    ...
    setTimeout(() => {
      if (tag) {
        Message.error(msg)
      }
    })
  }
)

接下来,需要考虑的是,如何在业务代码里改变标识变量

naive方案1:一个全局的变量或者方法

这个方案非常的不靠谱,若在其它代码里改变了这个全局变量,就嗝屁,并且N个接口公用一个标识变量,只能是同一个状态。

帅气方案2:

request.interceptors.response.use(
  (response) => response.data,
  (error) => {
    ...
    let isShowNormalError = true
    const hideNormalError = () => isShowNormalError = false

    setTimeout(() => {
      if (isShowNormalError) {
        Message.error(msg)
      }
    })

    return Promise.reject({ ...error.response, hideNormalMessage }) // 在error.response上添加方法
  }
)

业务代码:

someAPIFN()
  .then()
  .catch({ data, hideNormalMessage }) {
    // 业务代码
    hideNormalMessage()
  }

兼容旧代码

目前的方案需要对现存代码做修改,对进行特殊处理的接口添加hideNormalMessage()。如果不想全局搜索添加代码(懒),可以根据业务来进行兼容。下面讲一下我结合业务代码进行的兼容处理(非常不推荐)。

request.interceptors.response.use(
  (response) => response.data,
  (error) => {
    // warning,和业务代码深度耦合,不推荐
    const hasMessageBeforeCatch = !!document.querySelector('.el-message')
    
    ...

    let isShowNormalError = true
    const hideNormalError = () => isShowNormalError = false

    setTimeout(() => {
      const hasMessageAfterCatch = document.querySelector('.el-message')

      // 调用catch前没有message,调用catch后有message,表示message是在catch过程中产生
      const madeMessageWhenCatch = !hasMessageBeforeCatch && hasMessageAfterCatch

      if (isShowNormalError && !madeMessageWhenCatch) {
        Message.error(msg)
      }
    })

    return Promise.reject({ ...error.response, hideNormalMessage }) // 在error.response上添加方法
  }
)

逻辑:如果在catch中使用了Message,就不展示统一错误处理

总结

这个解决方案的关键在于使用setTimeout使得统一错误处理“落后”于业务代码,并在Promise.reject的参数中添加控制函数使得业务代码可以决定是否展示统一错误处理。稍作抽象与封装就可以形成一个业务无关、框架无关的统一错误处理方案。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。

标签:
Axios统一错误处理

免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
评论“详解Axios统一错误处理与后置”
暂无“详解Axios统一错误处理与后置”评论...

《魔兽世界》大逃杀!60人新游玩模式《强袭风暴》3月21日上线

暴雪近日发布了《魔兽世界》10.2.6 更新内容,新游玩模式《强袭风暴》即将于3月21 日在亚服上线,届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。

艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕,并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时,他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中,玩家将会进入一个全新的海盗主题大逃杀式限时活动,其中包含极高的风险和史诗级的奖励。

《强袭风暴》不是普通的战场,作为一个独立于主游戏之外的活动,玩家可以用大逃杀的风格来体验《魔兽世界》,不分职业、不分装备(除了你在赛局中捡到的),光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式,玩家在加入海盗主题的预赛大厅区域前,可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹,《巨龙崛起》和《魔兽世界:巫妖王之怒 经典版》的玩家都可以获得奖励。