Hoe werkt error handling in GraphQL?

Question

IT Interview Practice · Accepted Answer

GraphQL geeft bij een geslaagd transport altijd HTTP **200** terug; problemen worden gerapporteerd in de response-body, niet in de statuscode. Een response heeft twee top-level keys: **`data`** en **`errors`**, en beide kunnen tegelijk aanwezig zijn — dat is **partial data**.

## Partial data + de errors-array

Als de resolver van één veld een exception gooit, wordt dat veld `null`, wordt er een entry aan `errors` toegevoegd, maar wordt elk ander veld nog steeds geresolvet. De client krijgt wat is gelukt plus een beschrijving van wat is misgegaan.

```json
{
  "data": { "user": { "name": "Ada", "posts": null } },
  "errors": [
    {
      "message": "Failed to load posts",
      "path": ["user", "posts"],        // precies welk veld faalde
      "extensions": { "code": "DOWNSTREAM_TIMEOUT" }
    }
  ]
}
```

Het veld **`extensions.code`** draagt een machine-leesbare error code zodat clients erop kunnen vertakken. Of een gegooid veld alleen zichzelf op null zet of naar boven bubbelt, hangt af van **nullability**: een non-null veld (`posts: [Post!]!`) dat een fout geeft, zet zijn dichtstbijzijnde nullable parent op null.

```js
import { GraphQLError } from "graphql";

Veel teams modelleren **verwachte** fouten (validatie, "email taken") ook als onderdeel van het schema via union/result types, en reserveren de `errors`-array voor **onverwachte** fouten — zo blijft de typering van het happy path schoon.

## Waarom het belangrijk is

Interviewers peilen of je weet dat errors in de body leven met partial `data`, dat codes in `extensions` thuishoren, en dat nullability bepaalt hoe ver een fout bubbelt. GraphQL-errors verwarren met HTTP-statuscodes is een klassiek teken dat iemand alleen REST heeft gebruikt.

Partial data + de errors-array

Waarom het belangrijk is

Gerelateerde vragen