Apollo Client 4.0 错误处理机制的重大改进

在 Apollo Client 4.0 版本中，开发团队对错误处理机制进行了重大重构，将原先单一的 ApolloError 类型拆分为多个专门的错误类型。这一改进解决了长期以来存在的设计问题，使错误处理更加清晰和类型安全。

原有设计的问题

在之前的版本中，Apollo Client 使用一个统一的 ApolloError 类来处理所有类型的错误，包括网络错误和 GraphQL 错误。这个类包含两个主要属性：

• networkError：用于网络层错误
• graphqlErrors：用于 GraphQL 执行错误

然而，这种设计存在几个明显的问题：

1. 逻辑矛盾：网络错误和 GraphQL 错误实际上是互斥的，一个请求要么遇到网络问题，要么服务器成功响应但包含 GraphQL 错误，不可能同时发生。但原设计允许同时设置这两个属性，导致潜在的矛盾状态。

2. 处理逻辑复杂：开发者需要检查两个不同的属性来确定错误类型，增加了代码复杂度。同时，不同错误类型在框架内部的处理方式也不同（如 useQuery 和 useSuspenseQuery 对错误的处理策略差异），但类型系统无法体现这些差异。

3. 类型信息缺失：统一的错误类型无法通过类型系统表达不同错误的本质区别，开发者需要通过运行时检查来确定错误类型。

新设计方案

4.0 版本引入了专门的错误类型：

1. ApolloNetworkError：专门表示网络层错误，如连接失败、超时等。

2. ApolloGraphQLError：专门表示 GraphQL 执行错误，包含服务器返回的错误信息集合。

这种分离带来了多个优势：

• 类型安全：通过不同的类明确区分错误类型，TypeScript 类型系统可以更好地帮助开发者处理错误。

• 简化API：查询结果对象不再需要维护两个错误属性，只需一个 error 属性，其类型为特定错误类的实例。

• 更清晰的错误处理：开发者可以使用类型检查或 switch 语句清晰地处理不同错误：

if (error instanceof ApolloNetworkError) {
  // 处理网络错误
} else if (error instanceof ApolloGraphQLError) {
  // 处理GraphQL错误
}

对开发者的影响

这一变更属于破坏性更新，需要开发者调整现有代码：

1. 原先检查 error.networkError 或 error.graphqlErrors 的代码需要改为检查错误类型。

2. 错误处理链接（如 onError）现在会接收到更具体的错误实例，可以更精确地处理不同错误。

3. 类型定义更加严格，有助于在编译时捕获错误处理逻辑的问题。

设计理念

这一改进体现了几个重要的软件设计原则：

1. 单一职责原则：每个错误类只负责表示一种特定类型的错误。

2. 显式优于隐式：通过类型系统明确表达不同错误的区别，而不是依赖文档说明。

3. 使非法状态不可表示：通过类型设计避免不可能的状态（如同时存在网络和GraphQL错误）。

对于使用 Apollo Client 的开发者来说，这一改进虽然需要一些迁移工作，但长期来看将显著提高代码的健壮性和可维护性。新的错误处理机制更符合现代 TypeScript 的最佳实践，能够更好地利用类型系统的优势来防止错误。