GraphQL Error Handling in Spring Boot
Fast recall
Quick revision
Core answer
Whether you understand GraphQL's "HTTP 200 with top-level `errors`" shape, can classify errors (validation, authorization, unexpected) and return partial data, and use `DataFetcherExceptionResolver` in Spring for GraphQL.
Letting a raw Java stack trace leak into the `errors[0].message` field — exposes internals and confuses clients. Or conflating HTTP status errors (400/500) with GraphQL errors — a valid GraphQL response is always 200 unless the body itself was malformed.
Discuss error classification (`ErrorType.BAD_REQUEST`, `UNAUTHORIZED`, `FORBIDDEN`, `NOT_FOUND`, `INTERNAL_ERROR`), carrying extension fields like `code` and `traceId`, partial responses with per-field nulls, and Apollo/Relay client error handling conventions.
Interview-ready guide
Interview answer
The biggest mental shift from REST to GraphQL error handling is that GraphQL always returns HTTP 200. Errors don't live in status codes — they live in a top-level errors array alongside whatever data succeeded. Partial success is normal: a response can return 49 books successfully and an error for the 50th, all in the same JSON body.
How error mapping works in Spring:
- Extend
DataFetcherExceptionResolverAdapterto map Java exceptions to GraphQL errors; domain exceptions likeBookNotFoundExceptionbecome typed errors with aNOT_FOUNDclassification and safe metadata in theextensionsmap - Clients branch on
extensions.code, never on the human-readable message — messages are for humans, codes are for client logic; thepathfield identifies exactly which query field triggered the error - Unhandled exceptions auto-sanitize to
INTERNAL_ERRORso stack traces never leak to clients
Validation errors — errors-as-data pattern:
- For mutation validation, return a payload type with a
UserErrorlist that maps each error to a form field rather than throwing exceptions; clients mapfield: "title"to form inputs programmatically - Reserve the top-level
errorsarray for unexpected system failures — things the client can't recover from — andUserErrorfor business validation failures
Null bubbling — the production gotcha:
- If a non-null field's resolver throws, GraphQL nulls the parent; if the parent is also non-null, it keeps cascading upward; a single author resolver failure can erase an entire list of 50 books if every ancestor is marked non-null
- Default fields to nullable unless they're truly invariant like
id; tightening nullability later is non-breaking, loosening it is breaking
I recommend implementing DataFetcherExceptionResolver from day one and testing that specific exceptions produce specific extensions.code values — without explicit error mapping, every failure looks like INTERNAL_ERROR in client logs.
GraphQL Error Handling in Spring Boot
Direct Answer
GraphQL always returns HTTP 200 with a JSON body. Errors appear in a top-level errors array alongside partial data. Spring for GraphQL provides DataFetcherExceptionResolver to map exceptions to GraphQLError objects. You should distinguish between user errors (validation failures, returned as data in the payload) and system errors (returned in the errors array).
Common Mistakes & Pitfalls
Letting a raw Java stack trace leak into the errors[0].message field — exposes internals and confuses clients. Or conflating HTTP status errors (400/500) with GraphQL errors — a valid GraphQL response is always 200 unless the body itself was malformed.
Check your understanding
Answer these without looking back at the article.
- What is null bubbling and how does it interact with error handling?
- How do you hide internal error details from clients in production?
- What is the difference between returning errors in the payload vs the top-level errors array?
Related interview prep categories
1Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.