Miten virheenkäsittely toimii GraphQL:ssä?

Question

IT Interview Practice · Accepted Answer

GraphQL palauttaa aina HTTP-koodin **200** onnistuneelle transportille; ongelmat raportoidaan vastauksen rungossa, ei status-koodissa. Vastauksella on kaksi ylimmän tason avainta: **`data`** ja **`errors`**, ja molemmat voivat olla läsnä yhtä aikaa — tämä on **osittainen data** (partial data).

## Osittainen data + errors-taulukko

Jos yhden kentän resolver heittää poikkeuksen, siitä kentästä tulee `null`, `errors`-taulukkoon lisätään merkintä, mutta jokainen muu kenttä ratkeaa silti. Client saa sen mikä onnistui plus kuvauksen siitä mikä epäonnistui.

```json
{
  "data": { "user": { "name": "Ada", "posts": null } },
  "errors": [
    {
      "message": "Failed to load posts",
      "path": ["user", "posts"],        // exactly which field failed
      "extensions": { "code": "DOWNSTREAM_TIMEOUT" }
    }
  ]
}
```

**`extensions.code`**-kenttä kuljettaa koneluettavan virhekoodin, jotta clientit voivat haarautua sen perusteella. Se, nulaako heittänyt kenttä vain itsensä vai kuplaako virhe ylöspäin, riippuu **nullabilitysta**: non-null-kenttä (`posts: [Post!]!`), joka virheytyy, nulaa lähimmän nullable-parentinsa sen sijaan.

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

Monet tiimit mallintavat myös **odotetut** virheet (validointi, "sähköposti on jo käytössä") osaksi schemaa union- tai result-tyyppien avulla, ja varaavat `errors`-taulukon **odottamattomille** virheille — pitäen happy pathin tyypityksen siistinä.

## Miksi se on tärkeää

Haastattelijat tunnustelevat, tiedätkö että virheet elävät rungossa osittaisen `data`n kanssa, että koodit kuuluvat `extensions`iin, ja että nullability ohjaa sitä, kuinka pitkälle virhe kuplaa. GraphQL-virheiden sekoittaminen HTTP-status-koodeihin on klassinen merkki siitä, että joku on käyttänyt vain RESTiä.

Osittainen data + errors-taulukko

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset