हम त्रुटियों का लेखा-परीक्षण करते हैं

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

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

चित्र यहाँ से

मामलों की एक छोटी संख्या, आमतौर पर बाहरी दुनिया के साथ बातचीत से जुड़ी होती है, जैसे कि नेटवर्क गतिविधि, ऑपरेशन को दोहराने के लिए यह तय करने के लिए कॉल करने वाले को त्रुटि की प्रकृति की जांच करने की आवश्यकता होती है।

पैकेज लेखकों के लिए एक सामान्य आवश्यकता ज्ञात सार्वजनिक प्रकार की त्रुटियों को वापस करना है ताकि कॉल करने वाले टाइप एस्टर का उपयोग कर सकें और उन्हें विस्तार से जांच सकें। मेरा मानना ​​है कि इस अभ्यास से कई अवांछनीय परिणाम निकलते हैं:

• खुले प्रकार की त्रुटियां पैकेज एपीआई के साथ "संपर्क क्षेत्र" को बढ़ाती हैं।
• नई कार्यान्वयन केवल इंटरफ़ेस घोषणा में निर्दिष्ट प्रकारों को वापस करना चाहिए, भले ही वे अच्छी तरह से फिट न हों।
• कोड में जोड़े जाने के बाद त्रुटि का प्रकार, एपीआई को नाजुक बनाते हुए, संगतता को तोड़े बिना बदला या नहीं बदला जा सकता है।

अपेक्षित व्यवहार की पुष्टि करें, त्रुटि प्रकार की नहीं

यह दावा न करें कि त्रुटि मान एक विशिष्ट प्रकार है, बल्कि यह दावा करें कि मूल्य एक विशिष्ट व्यवहार को लागू करता है।

यह वाक्य गो निहित इंटरफेस की प्रकृति के अनुरूप है, और विरासत आधारित भाषाओं की प्रकृति का [उपप्रकार] नहीं है। इस उदाहरण पर विचार करें:

func isTimeout(err error) bool { type timeout interface { Timeout() bool } te, ok := err.(timeout) return ok && te.Timeout() } 

यह निर्धारित करने के लिए कि टाइमआउट इंटरफ़ेस को लागू करने में त्रुटि का समय समाप्त हो गया था, यह निर्धारित करने के लिए कॉलर टाइमटाइम () का उपयोग कर सकता है, और फिर पुष्टि कर सकता है कि क्या त्रुटि का समय समाप्त हो गया था - सभी प्रकार या स्रोत के बारे में कुछ भी जानने के बिना त्रुटि मान।

यह विधि त्रुटियों को लपेटना संभव बनाती है, एक नियम के रूप में, पुस्तकालयों के साथ जो त्रुटि पथ में स्पष्टीकरण जोड़ते हैं; बशर्ते कि लिपटे त्रुटि प्रकार भी त्रुटि इंटरफ़ेस को लागू करते हैं जो वे लपेटते हैं।

यह एक अघुलनशील समस्या की तरह लग सकता है, लेकिन व्यवहार में कुछ सामान्य रूप से स्वीकृत इंटरफ़ेस विधियां हैं, इसलिए टाइमआउट (अस्थायी) और अस्थायी () बूल उपयोग मामलों की एक विस्तृत श्रृंखला को कवर करेगा।

निष्कर्ष में

अपेक्षित व्यवहार की पुष्टि करें, त्रुटि प्रकार की नहीं

पैकेज लेखकों के लिए

यदि आपका पैकेज अस्थायी प्रकृति की त्रुटियों को उत्पन्न करता है, तो सुनिश्चित करें कि आप त्रुटि प्रकार लौटाते हैं जो उपयुक्त इंटरफ़ेस विधियों को लागू करते हैं। यदि आप आउटपुट त्रुटि मानों को लपेटते हैं, तो सुनिश्चित करें कि आपके रैपर इंटरफ़ेस (ओं) का समर्थन करते हैं, जिसके साथ मूल त्रुटि मूल्य लागू होता है।

पैकेज उपयोगकर्ताओं के लिए

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

लेखक के बारे में

इस लेख के लेखक, डेव चेनी , गो के लिए कई लोकप्रिय पैकेजों के लेखक हैं, उदाहरण के लिए, https://github.com/pkg/errors और https://github.com/davecheney/httpstat ।

अनुवादक से

यद्यपि मूल लेख को 2014 के अंत तक दिनांकित किया गया है, लेकिन मुझे ऐसा लगता है कि इसने अपनी प्रासंगिकता नहीं खोई है। वर्णित दृष्टिकोण कुछ पैकेजों में पाया जाता है, जबकि बाकी त्रुटियों के लिए सामान्य दृष्टिकोण का उपयोग करते हैं।

सामग्री की स्पष्टता बढ़ाने के लिए पाठ में संपादन स्वागत योग्य है!