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

在业务开发中，前后端团队共同约定了接口的数据结构，当接口出现异常时，需要将异常信息展示给用户。在业务代码中重复编写catch语句来展示错误信息并不优雅。为了解决这个问题，我们可以采用统一错误处理机制。本文将结合具体业务场景，介绍如何使用axios实现统一错误处理，并结合定制错误信息展示的问题进行。

在实际业务场景中，后端通过http状态标识接口状态，错误信息包含在response的data里。前端使用element-ui的Message组件展示错误信息，并通过axios进行请求处理。axios允许我们通过在响应前设置来处理响应数据，这使得我们可以在业务代码处理响应之前对错误进行统一处理。

为了统一处理响应错误，我们可以使用axios的响应。在中，我们可以定义统一的错误处理逻辑。例如，当接口返回特定的http状态码时（如401），我们可以跳转到登录页面；对于其他错误，我们可以将错误信息展示给用户。这样，我们可以在业务代码中避免重复编写错误处理逻辑。

有时我们需要针对某些接口展示定制的错误信息。这时，我们需要找到一种方法让业务代码能够决定是否隐藏统一的错误提示。一种解决方案是使用setTimeout函数将统一错误提示放到下一个循环执行，并通过一个标识变量来控制是否执行统一错误提示。这样，我们可以在业务代码中根据需要改变这个标识变量来实现定制化的错误信息展示。需要注意的是，标识变量的使用应避免全局化，以免受到其他代码的影响。一种可能的解决方案是将标识变量与特定的接口绑定，或者使用闭包来隔离变量的作用域。

通过axios的响应实现统一错误处理可以大大提高代码的优雅性和可维护性。结合setTimeout和标识变量可以解决定制错误信息展示的问题。在实际应用中，我们需要根据具体需求进行灵活调整和优化。希望本文的介绍能给大家在Axios统一错误处理方面带来一些启示和帮助。帅气的请求处理方案升级版

在一个充满各种接口调用与数据交互的现代项目中，优雅地处理请求响应和错误变得尤为重要。让我们深入一个具体的方案，这个方案基于请求来增强我们的错误处理能力。我们将尝试在业务代码中融入这一策略，以实现更精细的控制。

我们来看看如何在请求中处理响应和错误：

对于每一个请求响应，我们都关注它的数据部分。为此，我们可以使用中的response处理函数来确保我们只处理响应的数据部分：

```javascript

requestterceptors.response.use(

(response) => response.data, // 仅关注响应的数据部分

(error) => {

// 错误处理逻辑开始

let isShowNormalError = true; // 默认展示普通错误信息

const hideNormalError = () => isShowNormalError = false; // 提供隐藏错误信息的函数

// 利用setTimeout来确保错误处理逻辑在业务代码之后执行

setTimeout(() => {

if (isShowNormalError) {

// 如果需要展示普通错误信息，并且该错误信息不是在业务代码的错误处理过程中产生的，则展示错误信息

Message.error(msg);

}

});

// 在返回的Promise中携带额外的hideNormalMessage方法供业务代码使用

return Promise.reject({ ...error.response, hideNormalMessage });

}

);

```

接下来，让我们看看如何在业务代码中融入这一策略。假设我们有一个API调用函数someAPIFN()，我们可以在其回调中使用新的错误处理方式：

```javascript

someAPIFN()

.then(/ 成功处理逻辑 /) // 这里可以省略具体的成功处理逻辑细节

.catch({ data, hideNormalMessage }) => { // 使用解构赋值获取自定义的hideNormalMessage函数

// 业务代码逻辑开始...