详解Axios统一错误处理与后置

Z时代
2024-01-10
分类：综合

问题

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

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

业务场景

后端通过http状态标识接口状态，错误信息在response的data里

前端的处理逻辑是使用element-ui的Message展示错误信息

使用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上添加方法
  }
)