GraphQL vždy vrací pro úspěšný transport HTTP 200; problémy se hlásí v těle odpovědi, nikoli ve stavovém kódu. Odpověď má dva klíče nejvyšší úrovně: data a errors, a oba mohou být přítomny zároveň — to jsou částečná data.
Pokud resolver jednoho pole vyhodí výjimku, dané pole se stane , do se přidá záznam, ale všechna ostatní pole se stále resolvují. Klient dostane to, co uspělo, plus popis toho, co selhalo.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // přesně které pole selhalo
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Pole extensions.code nese strojově čitelný kód chyby, takže se na něj klienti mohou větvit. Zda vyhozené pole vynuluje jen sebe, nebo probublá výš, závisí na nullability: non-null pole (posts: [Post!]!), které selže, vynuluje svého nejbližšího nullable rodiče.
import { GraphQLError } from "graphql";
const resolvers = {
Mutation: {
transfer: (_p, args, ctx) => {
if (!ctx.user) {
// připoj stabilní kód, na který se klienti mohou přepnout; skryj interní detaily
throw new GraphQLError("Not authenticated", {
extensions: { code: "UNAUTHENTICATED" },
});
}
// ...
},
},
};
Mnoho týmů také modeluje očekávané chyby (validace, „email je obsazený“) jako součást schématu pomocí union/result typů a pole errors vyhrazuje pro neočekávaná selhání — tím udržuje typování šťastné cesty čisté.
Tazatelé zkoumají, zda víte, že chyby žijí v těle spolu s částečnými data, že kódy patří do extensions a že nullability řídí, jak daleko chyba probublá. Zaměňování GraphQL chyb za HTTP stavové kódy je klasický příznak toho, že někdo používal jen REST.
Knihovna IT otázek k pohovoru s podrobnými odpověďmi — od Junior po Senior.
Přispět