What if your API errors could actually help users fix problems faster?
Why Custom error extensions in GraphQL? - Purpose & Use Cases
Imagine you are building a GraphQL API and want to tell users exactly what went wrong when a request fails. Without custom error extensions, you only get a simple error message like "Something went wrong." This leaves users confused and developers guessing.
Relying on generic error messages is slow and frustrating. Users can't fix their input easily, and developers spend extra time debugging. It's like getting a "404" without knowing which page was missing or why.
Custom error extensions let you add extra details to errors, like error codes or helpful hints. This makes errors clear and actionable, improving user experience and speeding up debugging.
throw new Error('Invalid input')throw new GraphQLError('Invalid input', { extensions: { code: 'BAD_USER_INPUT', field: 'email' } })
Custom error extensions enable precise, meaningful error feedback that guides users and developers to quick solutions.
When a user submits a form with a wrong email format, the API can return an error with a code and field name, so the frontend highlights the exact input to fix.
Generic errors hide useful details and slow down fixes.
Custom error extensions add clear, structured info to errors.
This improves user guidance and developer debugging speed.
Practice
extensions in GraphQL error responses?Solution
Step 1: Understand the role of error extensions
Extensions add extra info to errors, such as codes or metadata.Step 2: Compare with other options
Extensions do not change data, speed, or hide errors; they enrich error info.Final Answer:
To provide extra information like error codes and details -> Option DQuick Check:
Extensions add info = B [OK]
- Thinking extensions change query data
- Assuming extensions hide errors
- Confusing extensions with performance tools
Solution
Step 1: Identify correct error object structure
The error object must have a message and an extensions object with code inside.Step 2: Check each option's syntax
{ message: 'Error', extensions: { code: 'BAD_REQUEST' } } correctly nests code inside extensions; others misuse or misplace fields.Final Answer:
{ message: 'Error', extensions: { code: 'BAD_REQUEST' } } -> Option CQuick Check:
Extensions is an object with code = D [OK]
- Putting code outside extensions
- Using extensions as a string or array
- Misnaming fields like error instead of message
{"errors":[{"message":"Not found","extensions":{"code":"NOT_FOUND","timestamp":"2024-06-01T12:00:00Z"}}]}What will the client see in the
extensions field?Solution
Step 1: Locate the extensions field in the error
The extensions field contains code and timestamp as key-value pairs.Step 2: Understand what client receives
The client sees the extensions object exactly as given, with code and timestamp.Final Answer:
{"code":"NOT_FOUND","timestamp":"2024-06-01T12:00:00Z"} -> Option AQuick Check:
Extensions content = A [OK]
- Confusing message with extensions
- Expecting extensions to be a string
- Ignoring extra fields like timestamp
{ message: 'Unauthorized', extensions: 'AUTH_ERROR' }Why does this cause a problem?
Solution
Step 1: Check the type of extensions field
Extensions must be an object with key-value pairs, not a string.Step 2: Identify the error cause
Using a string for extensions causes syntax or runtime errors in GraphQL.Final Answer:
Extensions must be an object, not a string -> Option AQuick Check:
Extensions type error = A [OK]
- Using string instead of object for extensions
- Ignoring GraphQL error format rules
- Assuming message content causes error
Solution
Step 1: Check the data types for extensions fields
The retry flag should be a boolean false, not string or null or number.Step 2: Validate each option's retry value
{ message: 'Timeout', extensions: { code: 'TIMEOUT', retry: false } } uses boolean false correctly; others use wrong types.Final Answer:
{ message: 'Timeout', extensions: { code: 'TIMEOUT', retry: false } } -> Option BQuick Check:
Boolean retry flag = C [OK]
- Using string 'no' instead of boolean false
- Using null or 0 for boolean flags
- Ignoring correct data types in extensions
Ready to prove it?
Pass the test and this pattern moves unknown
