GraphQL จะส่งคืน HTTP 200 เสมอเมื่อการรับส่งข้อมูล (transport) สำเร็จ ปัญหาต่าง ๆ ถูกรายงานใน body ของ response ไม่ใช่ที่ status code response มี key ระดับบนสุดสองตัวคือ data และ errors ซึ่งอาจปรากฏพร้อมกันได้ — นั่นคือ partial data (ข้อมูลบางส่วน)
หาก resolver ของ field หนึ่งโยน error ออกมา field นั้นจะกลายเป็น และมีรายการถูกเพิ่มเข้าไปใน แต่ field อื่น ๆ ทั้งหมดยังคง resolve ได้ตามปกติ client จะได้ทั้งส่วนที่สำเร็จพร้อมคำอธิบายว่าส่วนใดล้มเหลว
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exactly which field failed
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
field extensions.code พก error code ที่เครื่องอ่านได้ เพื่อให้ client ใช้แยกเงื่อนไขได้ ส่วนที่ว่า field ที่โยน error จะทำให้ตัวเองเป็น null เท่านั้นหรือจะลาม (bubble up) ขึ้นไป ขึ้นอยู่กับ nullability: field ที่เป็น non-null (posts: [Post!]!) เมื่อเกิด error จะทำให้ parent ที่เป็น nullable ตัวใกล้ที่สุดกลายเป็น null แทน
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" },
});
}
// ...
},
},
};
หลายทีมยังจำลอง error ที่ คาดการณ์ได้ (validation, "email ถูกใช้ไปแล้ว") ให้เป็นส่วนหนึ่งของ schema ผ่าน union/result type โดยสงวน array errors ไว้สำหรับความล้มเหลวที่ ไม่คาดคิด — เพื่อให้การกำหนดชนิดข้อมูลของ happy path สะอาด
ผู้สัมภาษณ์จะตรวจสอบว่าคุณรู้หรือไม่ว่า error อยู่ใน body ควบคู่กับ data บางส่วน, code ควรอยู่ใน extensions, และ nullability เป็นตัวควบคุมว่า error จะลามไปไกลแค่ไหน การสับสนระหว่าง error ของ GraphQL กับ HTTP status code เป็นสัญญาณคลาสสิกว่าใครบางคนเคยใช้แต่ REST
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค