पिछले एक दशक में, हमने इस तथ्य का सफलतापूर्वक दोहन किया है कि गो त्रुटियों को मूल्यों के रूप में संभालता है। हालाँकि मानक लाइब्रेरी में त्रुटियों के लिए न्यूनतम समर्थन था: केवल त्रुटियाँ। errors.New और fmt.Errorf फ़ंक्शन जो केवल एक संदेश वाली त्रुटि उत्पन्न करते हैं - अंतर्निहित इंटरफ़ेस गो-प्रोग्रामर को किसी भी जानकारी को जोड़ने की अनुमति देता है। आप सभी की जरूरत है एक प्रकार है कि Error विधि को लागू करता है:

 type QueryError struct { Query string Err error } func (e *QueryError) Error() string { return e.Query + ": " + e.Err.Error() } 

इस प्रकार की त्रुटियां सभी भाषाओं में पाई जाती हैं और टाइमस्टैम्प से लेकर फ़ाइल नाम और सर्वर पते तक कई प्रकार की जानकारी संग्रहीत करती हैं। निम्न-स्तरीय त्रुटियां जो अतिरिक्त संदर्भ प्रदान करती हैं, अक्सर उल्लेखित हैं।

पैटर्न, जब एक त्रुटि में दूसरा होता है, तो गो में अक्सर सामना होता है कि गो 1.13 में एक गर्म चर्चा के बाद इसका स्पष्ट समर्थन जोड़ा गया था। इस लेख में, हम मानक पुस्तकालय में परिवर्धन को देखेंगे जो उल्लिखित समर्थन प्रदान करते हैं: त्रुटियों के पैकेज में तीन नए कार्य और fmt.Errorf लिए एक नया स्वरूपण आदेश।

परिवर्तनों के बारे में विस्तार से चर्चा करने से पहले, आइए बात करते हैं कि भाषा के पिछले संस्करणों में त्रुटियों की जांच और निर्माण कैसे किया गया।

1.13 से पहले त्रुटियां

त्रुटि अनुसंधान

गो में त्रुटियां अर्थ हैं। कार्यक्रम इन मूल्यों के आधार पर विभिन्न तरीकों से निर्णय लेते हैं। अधिकांश बार, त्रुटि की तुलना यह देखने के लिए की जाती है कि ऑपरेशन विफल हो गया है।

 if err != nil { // something went wrong } 

कभी-कभी हम नियंत्रण मूल्य का पता लगाने के लिए त्रुटि की तुलना करते हैं और देखते हैं कि क्या कोई विशिष्ट त्रुटि हुई है।

 var ErrNotFound = errors.New("not found") if err == ErrNotFound { // something wasn't found } 

त्रुटि मान किसी भी प्रकार का हो सकता है जो भाषा में परिभाषित त्रुटि इंटरफ़ेस को संतुष्ट करता है। एक प्रोग्राम एक अधिक विशिष्ट प्रकार के त्रुटि मान को देखने के लिए एक प्रकार के बयान या एक प्रकार के स्विच का उपयोग कर सकता है।

 type NotFoundError struct { Name string } func (e *NotFoundError) Error() string { return e.Name + ": not found" } if e, ok := err.(*NotFoundError); ok { // e.Name wasn't found } 

जानकारी जोड़ना

अक्सर एक फ़ंक्शन कॉल स्टैक पर एक त्रुटि पारित करता है, इसमें जानकारी जोड़ते हैं, उदाहरण के लिए, त्रुटि होने पर क्या हुआ, इसका एक संक्षिप्त विवरण। यह करना आसान है, बस एक नई त्रुटि का निर्माण करें जिसमें पिछली त्रुटि से पाठ शामिल हो:

 if err != nil { return fmt.Errorf("decompress %v: %v", name, err) } 

fmt.Errorf का उपयोग करके एक नई त्रुटि fmt.Errorf हम मूल त्रुटि से पाठ को छोड़कर सब कुछ त्याग देते हैं। जैसा कि हमने QueryError उदाहरण में देखा, कभी-कभी आपको एक नई प्रकार की त्रुटि को परिभाषित करने की आवश्यकता होती है जिसमें कोड का उपयोग करके विश्लेषण के लिए इसे सहेजने के लिए मूल त्रुटि होती है:

 type QueryError struct { Query string Err error } 

कार्यक्रम *QueryError अंदर देख सकते हैं और मूल त्रुटि के आधार पर निर्णय ले सकते हैं। इसे कभी-कभी एक त्रुटि के अलिखित कहा जाता है।

 if e, ok := err.(*QueryError); ok && e.Err == ErrPermission { // query failed because of a permission problem } 

मानक लाइब्रेरी से os.PathError प्रकार एक और त्रुटि के दूसरे उदाहरण का एक और उदाहरण है।

1.13 में त्रुटियां

अनवाप विधि

1.13 में, errors और fmt मानक लाइब्रेरी संकुल fmt त्रुटियों को सरल बनाया जिसमें अन्य त्रुटियां हैं। सबसे महत्वपूर्ण सम्मेलन है, परिवर्तन नहीं: एक त्रुटि जिसमें कोई अन्य त्रुटि है, वह Unwrap विधि को लागू कर सकता है, जो मूल त्रुटि देता है। यदि e1.Unwrap() रिटर्न e2 , तो हम कहते हैं कि e1 e2 पैक करता है और आप e2 प्राप्त करने के लिए e1 को अनपैक कर सकते हैं।

इस अधिवेशन के अनुसार, आप QueryError पद्धति के ऊपर वर्णित QueryError प्रकार दे सकते हैं, जो इसमें निहित त्रुटि देता है:

 func (e *QueryError) Unwrap() error { return e.Err } 

त्रुटि को अनपैक करने के परिणाम में Unwrap विधि भी हो सकती है। बार-बार अनपैकिंग के माध्यम से प्राप्त त्रुटियों का क्रम, हम त्रुटियों की श्रृंखला को कहते हैं ।

Is और As के साथ त्रुटि जांच

1.13 में, errors जांच के लिए errors पैकेज में दो नए कार्य शामिल हैं: Is और As ।

errors.Is फ़ंक्शन फ़ंक्शन किसी मान के साथ एक त्रुटि की तुलना करता है।

 // Similar to: // if err == ErrNotFound { … } if errors.Is(err, ErrNotFound) { // something wasn't found } 

As फ़ंक्शन यह जाँचता है कि क्या त्रुटि एक विशेष प्रकार की है।

 // Similar to: // if e, ok := err.(*QueryError); ok { … } var e *QueryError if errors.As(err, &e) { // err is a *QueryError, and e is set to the error's value } 

सरलतम स्थिति में, errors.Is । errors.Is फंक्शन एक कंट्रोल एरर के साथ तुलना की तरह व्यवहार करता है, और एरर। errors.As फंक्शन एक प्रकार के स्टेटमेंट की तरह व्यवहार करता है। हालांकि, पैक्ड त्रुटियों के साथ काम करते समय, ये फ़ंक्शन श्रृंखला में सभी त्रुटियों का मूल्यांकन करते हैं। मूल त्रुटि की जांच करने के लिए ऊपर QueryError के QueryError उदाहरण को देखें:

 if e, ok := err.(*QueryError); ok && e.Err == ErrPermission { // query failed because of a permission problem } 

errors.Is का उपयोग कर errors.Is फ़ंक्शन, errors.Is इसे लिख सकते हैं:

 if errors.Is(err, ErrPermission) { // err, or some error that it wraps, is a permission problem } 

errors पैकेज में एक नया Unwrap फ़ंक्शन भी होता है जो त्रुटि के Unwrap पद्धति को कॉल करने का परिणाम देता है, या त्रुटि को Unwrap विधि नहीं होने पर nil लौटाता है। यह आमतौर पर errors.Is का उपयोग करने के लिए बेहतर errors.Is या errors.As के बाद से, वे आपको एक कॉल के साथ पूरी श्रृंखला की जांच करने की अनुमति देते हैं।

% W के साथ पैकेजिंग में त्रुटि

जैसा कि मैंने उल्लेख किया है, त्रुटि के लिए अतिरिक्त जानकारी जोड़ने के लिए fmt.Errorf फ़ंक्शन का उपयोग करना सामान्य अभ्यास है।

 if err != nil { return fmt.Errorf("decompress %v: %v", name, err) } 

1.13 में, fmt.Errorf फ़ंक्शन नए %w कमांड का समर्थन करता है। यदि यह है, तो fmt.Errorf द्वारा fmt.Errorf गई त्रुटि में fmt.Errorf पद्धति होगी जो %w तर्क लौटाती है, जो एक त्रुटि होनी चाहिए। अन्य सभी मामलों में, %w , %v समान है।

 if err != nil { // Return an error which unwraps to err. return fmt.Errorf("decompress %v: %w", name, err) } 

%w साथ त्रुटि को errors.Is यह errors.Is लिए उपलब्ध कराता है। errors.Is और errors.As ।

 err := fmt.Errorf("access denied: %w", ErrPermission) ... if errors.Is(err, ErrPermission) ... 

कब पैक करें?

जब आप fmt.Errorf या एक कस्टम प्रकार कार्यान्वयन का उपयोग करते हुए त्रुटि के लिए एक अतिरिक्त संदर्भ जोड़ते हैं, तो आपको यह तय करने की आवश्यकता है कि नई त्रुटि में मूल शामिल होगा या नहीं। इसका कोई एक उत्तर नहीं है, यह सब उस संदर्भ पर निर्भर करता है जिसमें नई त्रुटि पैदा होती है। उसे कॉलर दिखाने के लिए पैक करें। यदि यह कार्यान्वयन विवरण के प्रकटीकरण की ओर जाता है, तो त्रुटि को पैकेज न करें।

उदाहरण के लिए, एक io.Reader फ़ंक्शन की कल्पना करें जो io.Reader से एक जटिल डेटा संरचना को io.Reader । यदि कोई त्रुटि होती है, तो हम उस पंक्ति और स्तंभ की संख्या का पता लगाना चाहेंगे जहां यह हुआ था। यदि io.Reader से पढ़ते समय कोई त्रुटि हुई, तो हमें इसका कारण जानने के लिए इसे पैक करना होगा। चूंकि कॉलर को io.Reader फ़ंक्शन के साथ प्रदान किया गया था, इसलिए यह उत्पन्न होने वाली त्रुटि को दिखाने के लिए समझ में आता है।

एक अन्य मामला: एक फ़ंक्शन जो कई डेटाबेस कॉल करता है, शायद एक त्रुटि नहीं लौटना चाहिए जिसमें इन कॉलों में से एक का परिणाम पैक किया गया है। यदि इस फ़ंक्शन द्वारा उपयोग किया जाने वाला डेटाबेस कार्यान्वयन का हिस्सा है, तो इन त्रुटियों का खुलासा करना अमूर्तता का उल्लंघन करेगा। उदाहरण के लिए, यदि pkg पैकेज से LookupUser फ़ंक्शन Go database/sql पैकेज का उपयोग करता है, तो यह sql.ErrNoRows त्रुटि का सामना कर सकता है। यदि आप fmt.Errorf("accessing DB: %v", err) का उपयोग करके कोई त्रुटि fmt.Errorf("accessing DB: %v", err) , तो कॉल करने वाला अंदर नहीं देख सकता है और sql.ErrNoRows ढूंढ sql.ErrNoRows । लेकिन अगर फ़ंक्शन fmt.Errorf("accessing DB: %w", err) लौटाता है, तो fmt.Errorf("accessing DB: %w", err) लिख सकती है:

 err := pkg.LookupUser(...) if errors.Is(err, sql.ErrNoRows) … 

इस मामले में, फ़ंक्शन को हमेशा sql.ErrNoRows वापस करना चाहिए यदि आप क्लाइंट को अलग डेटाबेस के साथ पैकेज पर स्विच करते हुए भी नहीं तोड़ना चाहते हैं। दूसरे शब्दों में, पैकेजिंग आपके एपीआई का एक त्रुटि हिस्सा बनाता है। यदि आप भविष्य में एपीआई के हिस्से के रूप में इस त्रुटि के लिए समर्थन नहीं करना चाहते हैं, तो इसे पैकेज न करें।

यह याद रखना महत्वपूर्ण है कि चाहे आप इसे पैक करें या नहीं, त्रुटि अपरिवर्तित रहेगी। एक व्यक्ति जो इसे समझेगा उसके पास एक ही जानकारी होगी। पैकेजिंग के बारे में निर्णय लेना इस बात पर निर्भर करता है कि क्या कार्यक्रमों के लिए अतिरिक्त जानकारी की आवश्यकता है ताकि वे अधिक सूचित निर्णय ले सकें; या यदि आप अमूर्त के स्तर को बनाए रखने के लिए इस जानकारी को छिपाना चाहते हैं।

ईज़ एंड अस मेथड्स का उपयोग करके त्रुटि परीक्षण सेट करना

errors.Is फ़ंक्शन लक्ष्य मान के विरुद्ध श्रृंखला में प्रत्येक त्रुटि की जाँच करता है। डिफ़ॉल्ट रूप से, एक त्रुटि इस मान से मेल खाती है यदि वे समकक्ष हैं। इसके अलावा, श्रृंखला में एक त्रुटि इस पद्धति के कार्यान्वयन का उपयोग करके लक्ष्य मूल्य के साथ इसके अनुपालन की घोषणा कर सकती है।

Upspin पैकेज के कारण हुई त्रुटि पर विचार करें, जो टेम्पलेट के साथ त्रुटि की तुलना करती है और केवल नॉनजरो फ़ील्ड का मूल्यांकन करती है:

 type Error struct { Path string User string } func (e *Error) Is(target error) bool { t, ok := target.(*Error) if !ok { return false } return (e.Path == t.Path || t.Path == "") && (e.User == t.User || t.User == "") } if errors.Is(err, &Error{User: "someuser"}) { // err's User field is "someuser". } 

errors.As । errors.As समारोह भी विधि की सलाह देता है, यदि कोई हो।

त्रुटियां और पैकेज एपीआई

एक पैकेज जो त्रुटियों को लौटाता है (और अधिकांश पैकेज ऐसा करते हैं) को इन त्रुटियों के गुणों का वर्णन करना चाहिए जो एक प्रोग्रामर पर भरोसा कर सकता है। एक अच्छी तरह से डिज़ाइन किया गया पैकेज उन संपत्तियों के साथ वापसी की त्रुटियों से भी बच जाएगा, जिन पर भरोसा नहीं किया जा सकता।

सबसे सरल बात यह है कि क्या ऑपरेशन सफल रहा था, क्रमशः, मूल्य शून्य या गैर-शून्य। कई मामलों में, किसी अन्य जानकारी की आवश्यकता नहीं होती है।

यदि आपको पहचानने योग्य त्रुटि स्थिति को वापस करने के लिए फ़ंक्शन की आवश्यकता है, उदाहरण के लिए, "तत्व नहीं मिला", तो आप एक त्रुटि वापस कर सकते हैं जिसमें सिग्नल मूल्य पैक किया गया है।

 var ErrNotFound = errors.New("not found") // FetchItem returns the named item. // // If no item with the name exists, FetchItem returns an error // wrapping ErrNotFound. func FetchItem(name string) (*Item, error) { if itemNotFound(name) { return nil, fmt.Errorf("%q: %w", name, ErrNotFound) } // ... } 

त्रुटियों को प्रदान करने के लिए अन्य पैटर्न हैं जो कॉलर को शब्दार्थ की जांच कर सकते हैं। उदाहरण के लिए, सीधे नियंत्रण मूल्य, एक विशिष्ट प्रकार, या एक मूल्य जो एक विधेय फ़ंक्शन का उपयोग करके विश्लेषण किया जा सकता है, लौटाता है।

किसी भी स्थिति में, उपयोगकर्ता के आंतरिक विवरण को प्रकट न करें। जैसा कि अध्याय में उल्लेख किया गया है "जब यह पैकेजिंग के लायक है?", यदि आप किसी अन्य पैकेज से एक त्रुटि लौटाते हैं, तो इसे मूल त्रुटि को प्रकट करने के लिए न बदलें, जब तक कि आप भविष्य में इस विशिष्ट त्रुटि को वापस करने के लिए खुद को प्रतिबद्ध करने का इरादा न करें।

 f, err := os.Open(filename) if err != nil { // The *os.PathError returned by os.Open is an internal detail. // To avoid exposing it to the caller, repackage it as a new // error with the same text. We use the %v formatting verb, since // %w would permit the caller to unwrap the original *os.PathError. return fmt.Errorf("%v", err) } 

यदि कोई फ़ंक्शन पैक्ड सिग्नल मान या प्रकार के साथ कोई त्रुटि देता है, तो सीधे मूल त्रुटि वापस न करें।

 var ErrPermission = errors.New("permission denied") // DoSomething returns an error wrapping ErrPermission if the user // does not have permission to do something. func DoSomething() { if !userHasPermission() { // If we return ErrPermission directly, callers might come // to depend on the exact error value, writing code like this: // // if err := pkg.DoSomething(); err == pkg.ErrPermission { … } // // This will cause problems if we want to add additional // context to the error in the future. To avoid this, we // return an error wrapping the sentinel so that users must // always unwrap it: // // if err := pkg.DoSomething(); errors.Is(err, pkg.ErrPermission) { ... } return fmt.Errorf("%w", ErrPermission) } // ... } 

निष्कर्ष

यद्यपि हमने केवल तीन कार्यों और एक प्रारूपण आदेश पर चर्चा की, हम आशा करते हैं कि वे गो कार्यक्रमों में त्रुटि से निपटने में बहुत सुधार करने में मदद करेंगे। हम आशा करते हैं कि अतिरिक्त संदर्भ प्रदान करने के लिए पैकेजिंग एक सामान्य अभ्यास बन जाएगा, प्रोग्रामर बेहतर निर्णय लेने और बग को तेजी से खोजने में मदद करते हैं।

जैसा कि रोस कॉक्स ने गोफरकॉन 2019 में अपने भाषण में कहा था कि गो 2 के रास्ते में हम प्रयोग करते हैं, सरल करते हैं और जहाज करते हैं। और अब, इन परिवर्तनों को भेजना, हमने नए प्रयोगों के बारे में निर्धारित किया है।