深入理解axios-retry中的错误处理机制

axios-retry作为axios的一个扩展库，为HTTP请求提供了自动重试功能。本文将通过一个实际案例，分析axios-retry在错误处理方面的表现，并探讨如何完整获取错误响应信息。

问题背景

在使用axios-retry时，开发者发现当请求最终失败后，捕获的错误对象中丢失了原始错误响应中的详细信息。例如，原始错误响应可能包含业务相关的错误码和消息，但在最终抛出的错误对象中，这些关键信息却不见了。

错误对象分析

axios-retry在重试机制结束后抛出的错误对象通常包含以下基本结构：

{
    message: "Request failed with status code 400",
    name: "AxiosError",
    config: "请求配置信息",
    code: "ERR_BAD_REQUEST",
    status: 400
}

而实际上，完整的错误响应可能包含更多业务相关的详细信息：

{
    status: 400,
    errors: [
        {
            code: "118",
            message: "MY_SERVICE service required for tariff MY_TARIFF"
        }
    ]
}

解决方案探索

1. 直接访问response属性

虽然捕获的错误对象表面上看不到完整响应，但实际上可以通过error.response.data访问到完整的错误详情。这是因为axios的错误对象遵循特定结构，将HTTP响应保存在response属性中。

2. 使用拦截器处理

更优雅的解决方案是使用axios的拦截器机制。通过响应拦截器，可以统一处理错误响应，确保业务相关的错误信息能够被完整捕获和传递：

axios.interceptors.response.use(
    response => response,
    error => {
        if (error.response) {
            // 在这里可以提取完整的错误信息
            const businessError = error.response.data;
            // 可以抛出自定义错误或进行其他处理
            return Promise.reject(businessError);
        }
        return Promise.reject(error);
    }
);

3. 自定义重试逻辑

对于需要更精细控制的场景，可以在axios-retry的配置中自定义重试条件，同时记录完整的错误信息：

retryWrapper(axiosInstance, {
    retryCondition: (error) => {
        // 在这里可以访问error.response获取完整错误
        logger.error('Request failed:', error.response.data);
        return shouldRetry(error);
    }
});

最佳实践建议

1. 错误处理统一化：建议在应用层面建立统一的错误处理机制，确保所有HTTP错误都能被一致处理。

2. 日志记录完整：在重试逻辑中记录完整的错误信息，便于问题排查。

3. 错误对象封装：考虑封装自定义错误类，将HTTP状态码、业务错误码和消息等统一管理。

4. 重试策略优化：根据业务需求调整重试策略，例如只对特定状态码或错误类型进行重试。

通过以上方法，开发者可以确保在使用axios-retry时，既能享受自动重试带来的便利，又不会丢失任何关键的错误信息。