GraphQL सफल transport के लिए हमेशा HTTP 200 लौटाता है; समस्याओं की सूचना status code में नहीं, बल्कि response body में दी जाती है। एक response में दो top-level keys होते हैं: data और errors, और दोनों एक साथ मौजूद हो सकते हैं — यही partial data है।
यदि किसी एक field का resolver throw करता है, तो वह field बन जाता है, में एक entry जुड़ जाती है, लेकिन बाकी हर 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" }
}
]
}
extensions.code field एक machine-readable error code रखता है ताकि clients उसके आधार पर branch कर सकें। कोई throw हुआ field केवल खुद को null करता है या ऊपर तक bubble करता है, यह nullability पर निर्भर करता है: एक non-null field (posts: [Post!]!) जो error करता है, वह अपने खुद के बजाय अपने निकटतम nullable parent को 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" },
});
}
// ...
},
},
};
कई teams अपेक्षित (expected) errors (validation, "email taken") को schema के हिस्से के रूप में union/result types के ज़रिए model भी करती हैं, और errors array को अप्रत्याशित (unexpected) विफलताओं के लिए आरक्षित रखती हैं — जिससे happy-path typing साफ़ रहती है।
Interviewer यह जाँचते हैं कि क्या आप जानते हैं कि errors partial data के साथ body में रहती हैं, कि codes extensions में होने चाहिए, और कि nullability यह नियंत्रित करती है कि error कितनी दूर तक bubble करती है। GraphQL errors को HTTP status codes के साथ गड्डमड्ड करना एक classic संकेत है कि किसी ने केवल REST ही उपयोग किया है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें