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

问题

在进行业务开发的时候，前后端会对接口的数据结构进行约定，若接口有异常，需要将异常信息展示给用户知晓。这个流程里，数据结构是确定的（事先约定），数据的处理逻辑是相同的（展示给用户），如果在业务代码代码中重复的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的参数中添加控制函数使得业务代码可以决定是否展示统一错误处理。稍作抽象与封装就可以形成一个业务无关、框架无关的统一错误处理方案。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持三水点靠木。