Error handling on client in GraphQL - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the main purpose of error handling on the client in GraphQL?

To detect and manage errors returned by the GraphQL server, ensuring the user gets clear feedback and the app can respond gracefully.

beginner

In GraphQL, where are errors typically found in the response?

Errors are usually found in the errors field of the GraphQL response JSON, separate from the data field.

intermediate

How can a client handle partial data when a GraphQL response contains both data and errors?

The client can use the available data to update the UI and also show error messages for the parts that failed, allowing partial success handling.

beginner

What is a common method to catch network or server errors in a GraphQL client?

Using try-catch blocks around the fetch or client request, or handling promise rejections, to catch errors like network failures or server downtime.

intermediate

Why is it important to differentiate between GraphQL errors and network errors on the client?

Because GraphQL errors mean the server processed the request but found issues, while network errors mean the request didn't reach or get a response from the server. Handling them differently improves user experience.

Where does a GraphQL client find errors in a typical response?

A In the 'headers' field

B In the 'status' field

C In the 'errors' field

D In the 'data' field only

GraphQL responses include an 'errors' field when there are errors, separate from the 'data' field.

What should a client do if a GraphQL response has both 'data' and 'errors'?

A Use the data and show error messages for failed parts

B Ignore the data and show only errors

C Discard the entire response

D Retry the request immediately

Clients can use partial data and inform users about errors to provide a better experience.

Which of these is a network error example in GraphQL client context?

A Query syntax error

B Server returns 500 status

C Field not found in schema

D No internet connection

No internet connection is a network error; others are GraphQL or server errors.

How can a client catch network errors when making GraphQL requests?

A Using try-catch or promise rejection handlers

B By checking the 'errors' field in response

C By validating the query before sending

D By inspecting the 'data' field

Network errors occur outside the GraphQL response and are caught via try-catch or promise rejection.

Why handle GraphQL errors and network errors differently on the client?

A Because network errors contain error messages

B Because GraphQL errors mean server processed request; network errors mean no response

C Because GraphQL errors never affect UI

D Because network errors are always temporary

Understanding error types helps the client respond appropriately and inform the user correctly.

Explain how a GraphQL client should handle a response that contains both data and errors.

Think about showing what works and informing about what failed.

Describe the difference between GraphQL errors and network errors from a client perspective.

Consider where the error happens and what it means for the app.

Practice

1. What is the main purpose of error handling on the client side in GraphQL applications?

easy

A. To speed up the server response time

B. To keep the app stable and show clear messages to users

C. To change the GraphQL schema dynamically

D. To store data permanently on the client

Solution

1. Step 1: Understand client-side error handling

   Error handling on the client is about managing problems that happen when fetching or processing data, so the app doesn't crash.

2. Step 2: Identify the main goal

   The goal is to keep the app stable and inform users clearly about what went wrong.

3. Final Answer:

   To keep the app stable and show clear messages to users -> Option B

4. Quick Check:

   Error handling = stability + clear messages [OK]

Hint: Error handling means stability and clear user messages [OK]

Common Mistakes:

• Thinking error handling speeds up server
• Confusing error handling with schema changes
• Assuming error handling stores data

2. Which of the following is the correct way to catch errors from a GraphQL query using promises on the client?

easy

A. client.query(...).then(...).catch(error => handleError(error))

B. client.query(...).catch(...).then(error => handleError(error))

C. client.query(...).try(error => handleError(error))

D. client.query(...).error(error => handleError(error))

Solution

1. Step 1: Recall promise error handling syntax

   Promises use .then() for success and .catch() for errors.

2. Step 2: Match correct chaining

   The correct order is .then(...).catch(...). client.query(...).then(...).catch(error => handleError(error)) matches this.

3. Final Answer:

   client.query(...).then(...).catch(error => handleError(error)) -> Option A

4. Quick Check:

   Promise catch method = .catch() [OK]

Hint: Use .then() before .catch() to handle errors [OK]

Common Mistakes:

• Placing .catch() before .then()
• Using non-existent .try() or .error() methods
• Ignoring promise chaining order

3. Given the following code snippet, what will be logged if the GraphQL query fails?

client.query({ query: GET_USER })
  .then(response => console.log('User:', response.data.user))
  .catch(error => console.log('Error:', error.message))

medium

A. User: undefined

B. No output

C. User: null

D. Error: [error message from server]

Solution

1. Step 1: Understand promise flow on failure

   If the query fails, the .catch() block runs, logging the error message.

2. Step 2: Identify logged output

   The console logs 'Error:' followed by the error message from the server.

3. Final Answer:

   Error: [error message from server] -> Option D

4. Quick Check:

   Failed query triggers .catch() logging error [OK]

Hint: Failed queries run .catch() logging error message [OK]

Common Mistakes:

• Assuming .then() runs on failure
• Expecting 'User: undefined' instead of error
• Thinking no output appears on error

4. Identify the error in this client-side GraphQL error handling code:

try {
  const response = await client.query({ query: GET_POSTS });
  console.log(response.data.posts);
} catch {
  console.log('Failed to fetch posts');
}

medium

A. client.query does not return a promise

B. Using await inside try block is invalid

C. Missing error parameter in catch block

D. console.log cannot be used inside catch

Solution

1. Step 1: Review try-catch syntax

   The catch block should include an error parameter to access error details.

2. Step 2: Identify missing error parameter

   The code uses catch { ... } without (error), preventing access to the error details.

3. Final Answer:

   Missing error parameter in catch block -> Option C

4. Quick Check:

   catch needs (error) parameter [OK]

Hint: Always include error parameter in catch block [OK]

Common Mistakes:

• Omitting error parameter in catch
• Thinking await is invalid in try
• Believing client.query is not a promise

5. You want to show a friendly message to users when a GraphQL mutation fails due to network issues. Which approach correctly handles this on the client?

async function submitData() {
  try {
    const result = await client.mutate({ mutation: ADD_ITEM, variables: { name: 'Book' } });
    console.log('Item added:', result.data.addItem.id);
  } catch (error) {
    if (error.networkError) {
      alert('Network problem, please try again later.');
    } else {
      alert('An error occurred.');
    }
  }
}

hard

A. This code correctly distinguishes network errors and shows messages

B. The catch block should not check error properties

C. Using alert is not allowed in error handling

D. await cannot be used with client.mutate

Solution

1. Step 1: Analyze error handling logic

   The catch block checks if the error is a network error and shows a specific message.

2. Step 2: Confirm correct usage of await and alerts

   Using await with client.mutate is valid, and alerts are acceptable for user messages.

3. Final Answer:

   This code correctly distinguishes network errors and shows messages -> Option A

4. Quick Check:

   Check error.networkError to show friendly messages [OK]

Hint: Check error.networkError to show specific messages [OK]

Common Mistakes:

• Ignoring networkError property in catch
• Thinking alerts are disallowed
• Misunderstanding await usage with mutate