Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[4.0] Separate error objects #12200

Open
jerelmiller opened this issue Dec 9, 2024 · 0 comments
Open

[4.0] Separate error objects #12200

jerelmiller opened this issue Dec 9, 2024 · 0 comments

Comments

@jerelmiller
Copy link
Member

Currently we have a single error type ApolloError for gathering network errors and GraphQL errors. This class provides separate properties for each: networkError and graphqlErrors respectively.

The problem

These errors are mutually exclusive. According to our docs:

Executing GraphQL operations on a remote server can result in GraphQL errors or network errors.

The keyword here is or. Looking at our own code base, you'll see that in practice, this statement holds true.

The differences in these errors also have implications for how other parts of the library behave when an error is encountered. For example, useQuery always calls onError for network errors regardless of the error policy. useSuspenseQuery will always throw when a network error is encountered, regardless of the error policy.

By using a single type to model 2 distinct behaviors, this leaves room for impossible states. What happens if both networkError and graphqlErrors are set? Should networkError have priority over graphqlErrors because its more unexpected than the other? These properties are meant to be mutually exclusive, so we should model it this way.

Proposal

Rather than have multiple properties on a single error type, we'd like to split ApolloError up into distinct error classes. Doing so allows us to better model the distinction between different error types.

This has positive implications for other types of the code base as well. For example, our ApolloQueryResult has 2 error properties. This invites confusion as at times its not fully clear which of these properties I as a developer should be using to determine which to look at since both can be set under certain conditions.

Because we can treat these errors as mutually exclusive, we can narrow this down to a single error property set to the proper error instance.

const { error } = useQuery(...);

switch (error.name) {
  // names TBD
  case 'ApolloNetworkError':
    return <div>{error.message}</div>;

  case 'ApolloGraphQLError':
    return (
      <ul>
        {error.messages.map((message) => <li>{message}</li>)
      </ul>
    );
}
const errorLink = onError((error) => {
  // alternate style by checking its instance type
  if (error instanceof ApolloNetworkError) {
    // ...
  } else if (error instanceof ApolloGraphQLError) {
    // ...
  }
});
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant