Error handling on client in GraphQL - Step-by-Step Execution

Concept Flow - Error handling on client

Send GraphQL Query

↓

Receive Response

↓

Check for Errors?

No→Process Data

Yes↓

Handle Error

↓

Show Message or Retry

The client sends a query, receives a response, checks for errors, and either processes data or handles errors accordingly.

Execution Sample

GraphQL

query GetUser {
  user(id: "1") {
    name
  }
}

// Client checks response for errors

This GraphQL query requests a user's name by ID; the client then checks if the response has errors before using the data.

Execution Table

Step	Action	Response Content	Error Present?	Client Action	Output
1	Send query to server	N/A	N/A	Waiting for response	No output yet
2	Receive response	{"data":{"user":{"name":"Alice"}}}	No	Process data	Display user name: Alice
3	Send query to server	N/A	N/A	Waiting for response	No output yet
4	Receive response	{"errors":[{"message":"User not found"}],"data":null}	Yes	Handle error	Show error message: User not found
5	User retries query	N/A	N/A	Send query again	No output yet
6	Receive response	{"data":{"user":{"name":"Bob"}}}	No	Process data	Display user name: Bob

💡 Execution stops after successful data processing or after error handling and user decision.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6
response	null	{"data":{"user":{"name":"Alice"}}}	{"errors":[{"message":"User not found"}],"data":null}	{"data":{"user":{"name":"Bob"}}}
errorPresent	false	false	true	false
outputMessage	""	"Display user name: Alice"	"Show error message: User not found"	"Display user name: Bob"

Key Moments - 2 Insights

Why does the client check for errors even if data is present?

Because GraphQL responses can include both data and errors together, so the client must check the 'errors' field to know if something went wrong (see execution_table row 4).

What happens if the client ignores errors and processes data anyway?

The client might show incomplete or incorrect information, confusing users. The execution_table shows proper error handling at step 4 to avoid this.

Visual Quiz - 3 Questions

Look at the execution_table, what is the client output at step 2?

A Display user name: Alice

B Show error message: User not found

C No output yet

D Send query again

💡 Hint

Check the 'Output' column in execution_table row 2.

At which step does the client detect an error in the response?

A Step 2

B Step 6

C Step 4

D Step 1

💡 Hint

Look at the 'Error Present?' column in execution_table.

If the server always returns errors, how would the output column change?

A It would always show 'Display user name: ...'

B It would always show 'Show error message: ...'

C It would show 'No output yet' forever

D It would stop sending queries

💡 Hint

Refer to how errors are handled in execution_table rows 4 and 6.

Concept Snapshot

GraphQL client error handling:
- Send query and receive response
- Check if 'errors' field exists
- If errors, handle and show message
- Else, process and display data
- Optionally retry after errors

Full Transcript

In GraphQL client error handling, the client sends a query and waits for the server's response. Upon receiving the response, it checks if there is an 'errors' field. If no errors are present, the client processes and displays the data. If errors exist, the client handles them by showing an error message to the user. The user may retry the query, and the client repeats this process. This ensures users see correct information or clear error messages.

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