Error handling
Handling errors with Apollo
Any application, from simple to complex, can have its fair share of errors. It is important to handle these errors and when possible, report these errors back to your users for information. Using GraphQL brings a new set of possible errors from the actual GraphQL response itself. With that in mind, here are a few different types of errors:
GraphQL Errors: errors in the GraphQL results that can appear alongside successful data
Server Errors: server internal errors that prevent a successful response from being formed
Transaction Errors: errors inside transaction actions like
update
on mutationsUI Errors: errors that occur in your component code
Apollo Client Errors: internal errors within the core or corresponding libraries
Error policies
Much like fetchPolicy
, errorPolicy
allows you to control how GraphQL Errors from the server are sent to your UI code. By default, the error policy treats any GraphQL Errors as network errors and ends the request chain. It doesn't save any data in the cache, and renders your UI with the error
prop to be an ApolloError. By changing this policy per request, you can adjust how GraphQL Errors are managed in the cache and your UI. The possible options for errorPolicy
are:
none
: This is the default policy to match how Apollo Client 1.0 worked. Any GraphQL Errors are treated the same as network errors and any data is ignored from the response.ignore
: Ignore allows you to read any data that is returned alongside GraphQL Errors, but doesn't save the errors or report them to your UI.all
: Using theall
policy is the best way to notify your users of potential issues while still showing as much data as possible from your server. It saves both data and errors into the Apollo Cache so your UI can use them.
You can set errorPolicy
on each request like so:
1const MY_QUERY = gql`
2 query WillFail {
3 badField
4 goodField
5 }
6`;
7
8function ShowingSomeErrors() {
9 const { loading, error, data } = useQuery(MY_QUERY, { errorPolicy: 'all' });
10
11 if (loading) return <span>loading...</span>
12 return (
13 <div>
14 <h2>Good: {data.goodField}</h2>
15 <pre>Bad: {error.graphQLErrors.map(({ message }, i) => (
16 <span key={i}>{message}</span>
17 ))}
18 </pre>
19 </div>
20 );
21}
1const MY_QUERY = gql`
2 query WillFail {
3 badField
4 goodField
5 }
6`;
7
8const ShowingSomeErrors = () => (
9 <Query query={MY_QUERY} errorPolicy="all">
10 {({ error, data, loading }) => {
11 if (loading) return <span>loading...</span>
12 return (
13 <div>
14 <h2>Good: {data.goodField}</h2>
15 <pre>Bad: {error.graphQLErrors.map(({ message }, i) => (
16 <span key={i}>{message}</span>
17 ))}
18 </pre>
19 </div>
20 )
21 }}
22 </Query>
23);
Any errors reported will come under an error
prop along side the data returned from the cache or server.
Network Errors
When using Apollo Link, the ability to handle network errors is way more powerful. The best way to do this is to use the apollo-link-error
to catch and handle server errors, network errors, and GraphQL errors. If you would like to combine with other links, see composing links .
Usage
1import { onError } from "apollo-link-error";
2
3const link = onError(({ graphQLErrors, networkError }) => {
4 if (graphQLErrors)
5 graphQLErrors.map(({ message, locations, path }) =>
6 console.log(
7 `[GraphQL error]: Message: ${message}, Location: ${locations}, Path: ${path}`,
8 ),
9 );
10
11 if (networkError) console.log(`[Network error]: ${networkError}`);
12});
Options
Error Link takes a function that is called in the event of an error. This function is called with an object containing the following keys:
operation
: The Operation that erroredresponse
: The response from the servergraphQLErrors
: An array of errors from the GraphQL endpointnetworkError
: any error during the link execution or server response
Ignoring errors
If you want to conditionally ignore errors, you can set response.errors = null;
within the error handler:
1onError(({ response, operation }) => {
2 if (operation.operationName === "IgnoreErrorsQuery") {
3 response.errors = null;
4 }
5})