問題

在進行業務開發的時候，前后端會對接口的數據結構進行約定，若接口有異常，需要將異常信息展示給用戶知曉。這個流程里，數據結構是確定的（事先約定），數據的處理邏輯是相同的（展示給用戶），如果在業務代碼代碼中重復的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個接口公用一個標識變量，只能是同一個狀態。