GraphQL returnerar alltid HTTP 200 för en lyckad transport; problem rapporteras i svarskroppen, inte i statuskoden. Ett svar har två nycklar på toppnivå: data och errors, och båda kan finnas samtidigt — det är partiella data.
Om en resolver för ett fält kastar ett fel blir det fältet , en post läggs till i , men alla andra fält löses ändå. Klienten får det som lyckades plus en beskrivning av det som misslyckades.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exactly which field failed
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Fältet extensions.code bär en maskinläsbar felkod så att klienter kan förgrena sig på den. Om ett fält som kastar fel bara nollar sig självt eller bubblar uppåt beror på nullability: ett non-null-fält (posts: [Post!]!) som ger fel nollar istället sin närmaste nullbara förälder.
import { GraphQLError } from "graphql";
const resolvers = {
Mutation: {
transfer: (_p, args, ctx) => {
if (!ctx.user) {
// attach a stable code clients can switch on; hide internal details
throw new GraphQLError("Not authenticated", {
extensions: { code: "UNAUTHENTICATED" },
});
}
// ...
},
},
};
Många team modellerar även förväntade fel (validering, "e-post upptagen") som en del av schemat via union-/resultattyper, och reserverar errors-arrayen för oväntade fel — vilket håller typningen för happy path ren.
Intervjuare undersöker om du vet att fel finns i svarskroppen tillsammans med partiella data, att koder hör hemma i extensions, och att nullability styr hur långt ett fel bubblar. Att förväxla GraphQL-fel med HTTP-statuskoder är ett klassiskt tecken på att någon bara har använt REST.
Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera