सफल transport का लागि GraphQL ले सधैँ 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 बोक्छ ताकि client हरूले त्यसमा branch गर्न सकून्। throw भएको field ले आफैलाई मात्र null गर्छ कि माथितिर bubble हुन्छ भन्ने कुरा nullability मा भर पर्छ: error हुने non-null field (posts: [Post!]!) ले बरु आफ्नो नजिकको 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" },
});
}
// ...
},
},
};
धेरै team हरूले अपेक्षित error हरू (validation, "email taken") लाई union/result types मार्फत schema कै भागको रूपमा model गर्छन्, र errors array लाई अनपेक्षित असफलताहरूका लागि आरक्षित राख्छन् — जसले happy-path typing सफा राख्छ।
Interviewer हरूले तपाईंलाई error हरू partial data सँगै body मा बस्छन्, codes extensions मा हुन्छन्, र nullability ले error कति टाढासम्म bubble हुन्छ भन्ने नियन्त्रण गर्छ भन्ने थाहा छ कि छैन जाँच्छन्। GraphQL error हरूलाई HTTP status code सँग झुक्किनु भनेको कसैले REST मात्र प्रयोग गरेको छ भन्ने classic संकेत हो।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्