गो में त्रुटि से निपटने

हैलो, हब्रोस्क नागरिकों! गोलंग डेवलपर पाठ्यक्रम पहले से ही ओटीयूएस में शुरू हो रहा है , और हम इस विषय पर एक और उपयोगी पोस्ट साझा करने के लिए एक उत्कृष्ट अवसर पर विचार करते हैं। आज हम त्रुटियों के लिए गो के दृष्टिकोण के बारे में बात करते हैं। चलो शुरू हो जाओ!

अपने Go कोड में व्यावहारिक त्रुटि से निपटने में माहिर

यह पोस्ट बिफोर गेटिंग स्टार्टेड सीरीज़ का हिस्सा है, जहाँ हम गोलंग की दुनिया का पता लगाते हैं, गो में कोड लिखते समय आपको उन सुझावों और विचारों को साझा करना चाहिए जिन्हें आपको अपने स्वयं के धक्कों में नहीं भरना है।

मुझे लगता है कि आपके पास पहले से ही गो के साथ कम से कम बुनियादी अनुभव है, लेकिन अगर आपको लगता है कि कुछ बिंदु पर आप एक अपरिचित चर्चा सामग्री में आए थे, तो विराम देने में संकोच न करें, विषय का पता लगाएं और वापस आएं।

अब जब हमने अपना रास्ता साफ कर लिया है, तो चलें!

त्रुटि से निपटने के लिए गो का दृष्टिकोण सबसे विवादास्पद और दुरुपयोग सुविधाओं में से एक है। इस लेख में, आप त्रुटियों के लिए गो के दृष्टिकोण को जानेंगे, और समझेंगे कि वे "हूड के तहत" कैसे काम करते हैं। आप कुछ अलग तरीके सीखेंगे, गो स्रोत कोड और मानक पुस्तकालय की समीक्षा करें ताकि यह पता लगाया जा सके कि त्रुटियों को कैसे नियंत्रित किया जाता है और उनके साथ कैसे काम किया जाता है। आप सीखेंगे कि टाइप एसेरिज़न्स उन्हें संभालने में महत्वपूर्ण भूमिका क्यों निभाते हैं, और आपको आने वाले परिवर्तनों को हैंडल करने में त्रुटि दिखाई देगी, जिसे आप गो 2 में शुरू करने की योजना बनाते हैं।

प्रविष्टि

पहली चीजें पहली: गो में त्रुटियां कोई अपवाद नहीं हैं। डेव चेनी ने इस बारे में एक महाकाव्य ब्लॉग पोस्ट लिखा, इसलिए मैं आपको इसका उल्लेख करता हूं और सारांशित करता हूं: अन्य भाषाओं में आप सुनिश्चित नहीं हो सकते हैं कि कोई फ़ंक्शन अपवाद छोड़ सकता है या नहीं। अपवादों को फेंकने के बजाय, गो फ़ंक्शंस कई रिटर्न वैल्यूज़ का समर्थन करते हैं , और कन्वेंशन द्वारा इस सुविधा का उपयोग आमतौर पर एक फ़ंक्शन के परिणाम के साथ-साथ एक एरर चर के साथ किया जाता है।



यदि किसी कारण से आपका कार्य विफल हो सकता है, तो आपको शायद पहले से घोषित error प्रकार को वापस कर देना चाहिए। अधिवेशन द्वारा, त्रुटि को वापस करने से समस्या के बारे में कॉल करने वाले को संकेत मिलता है, और शून्य वापस करने को त्रुटि नहीं माना जाता है। इस प्रकार, आप फोन करने वाले को समझ जाएंगे कि कोई समस्या उत्पन्न हो गई है, और उसे इससे निपटने की आवश्यकता है: जो कोई भी आपके फ़ंक्शन को कॉल करता है, वह जानता है कि त्रुटि के लिए जाँच करने से पहले उसे परिणाम पर भरोसा नहीं करना चाहिए। यदि त्रुटि शून्य नहीं है, तो वह इसे जांचने और इसे संसाधित करने के लिए बाध्य है (लॉग, रिटर्न, रखरखाव, किसी तरह के रिट्री / सफाई तंत्र, आदि को कॉल करें)।


(3 // त्रुटि से निपटने
5 // जारी)

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


(4 // त्रुटियों की अनदेखी असुरक्षित है, और आपको त्रुटियों की जाँच करने से पहले परिणाम पर भरोसा नहीं करना चाहिए)
परिणाम त्रुटियों पर जाँच करने तक विश्वसनीय नहीं हो सकते

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


खाली आईडी अंधेरे और भयावह है।

गो में panic और recover मैकेनिज्म हैं, जो एक अन्य विस्तृत गो ब्लॉग पोस्ट में भी वर्णित हैं। लेकिन वे अपवादों का अनुकरण करने के इरादे से नहीं हैं। डेव के अनुसार, "जब आप गो में घबराते हैं, तो आप वास्तव में घबराते हैं: यह किसी और की समस्या नहीं है, यह पहले से ही एक गेमर है।" वे घातक हैं और आपके कार्यक्रम में दुर्घटना का कारण बन सकते हैं। रॉब पाइक ने कहा, "घबराओ मत," जो खुद के लिए बोलता है: आपको शायद इन तंत्रों से बचना चाहिए और इसके बजाय त्रुटियों को वापस करना चाहिए।

"त्रुटियां अर्थ हैं।"
"सिर्फ त्रुटियों के लिए जाँच न करें, लेकिन उन्हें कुशलता से संभालें।"
"घबराओ मत"
रोब पाइक की सभी बातें

हुड के नीचे

त्रुटि इंटरफ़ेस

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


स्रोत से त्रुटि इंटरफ़ेस

अपनी गलतियाँ करना मुश्किल नहीं है। उपयोगकर्ता संरचनाओं के विभिन्न दृष्टिकोण हैं जो Error() string विधि को लागू करते हैं। इस एकल विधि को लागू करने वाली किसी भी संरचना को एक वैध त्रुटि मान माना जाता है और इसे इस तरह से वापस किया जा सकता है।

आइए इनमें से कुछ तरीकों को देखें।

अंतर्निहित एररस्ट्रिंग संरचना

त्रुटि इंटरफ़ेस का सबसे अधिक उपयोग और व्यापक कार्यान्वयन अंतर्निहित errorString संरचना है। यह सबसे आसान कार्यान्वयन है जिसके बारे में आप सोच सकते हैं।


सोर्स: गो सोर्स कोड

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


(13 // आउटपुट :)

कोशिश

github.com/pkg/errors

एक और सरल उदाहरण pkg / त्रुटियों का पैकेज है। अंतर्निहित errors पैकेज से भ्रमित नहीं होना चाहिए जो आपने पहले के बारे में सीखा था, यह पैकेज अतिरिक्त महत्वपूर्ण विशेषताएं प्रदान करता है, जैसे त्रुटि रैपिंग, विस्तार, स्वरूपण और स्टैक ट्रेस रिकॉर्डिंग। आप पैकेज go get github.com/pkg/errors कर सकते हैं स्थापित करें go get github.com/pkg/errors ।



ऐसे मामलों में जहां आपको स्टैक ट्रेस या आवश्यक डीबगिंग जानकारी को अपनी त्रुटियों के साथ संलग्न करने की आवश्यकता होती है, इस पैकेज के New या Errorf उपयोग करके ऐसी त्रुटियां प्रदान की जाती हैं जो पहले से ही आपके स्टैक ट्रेस पर लिखी जाती हैं, और आप इसका उपयोग करके सरल मेटाडेटा भी संलग्न कर सकते हैं। प्रारूपण क्षमता। Errorf fmt.Formatter इंटरफ़ेस को लागू करता है, यानी आप इसे fmt पैकेज ( %s , %v , %+v , आदि) के रन का उपयोग करके प्रारूपित कर सकते हैं।


(// 6 या वैकल्पिक)

यह पैकेज errors.Wrap भी परिचय देता errors.Wrapf । ये फ़ंक्शंस संदेश का उपयोग करके त्रुटि के संदर्भ में जोड़ते हैं और उस स्थान पर एक स्टैक ट्रेस करते हैं जहां उन्हें बुलाया गया था। इस प्रकार, केवल त्रुटि वापस करने के बजाय, आप इसे संदर्भ और महत्वपूर्ण डीबगिंग डेटा के साथ लपेट सकते हैं।



अन्य त्रुटियों से त्रुटि आवरण Cause() error विधि का समर्थन करता है, जो उनकी आंतरिक त्रुटि देता है। इसके अलावा, उनका उपयोग errors.Cause(err error) error साथ किया जा सकता है। errors.Cause(err error) error फ़ंक्शन, जो रैपिंग त्रुटि में मुख्य आंतरिक त्रुटि को निकालता है।

हैंडलिंग में त्रुटि

अनुमोदन लिखें

त्रुटियों से निपटने के दौरान टाइप दावे महत्वपूर्ण भूमिका निभाते हैं। आप इंटरफ़ेस मूल्य से जानकारी निकालने के लिए उनका उपयोग करेंगे, और चूंकि त्रुटि हैंडलिंग उपयोगकर्ता इंटरफ़ेस के कार्यान्वयन के साथ जुड़ा हुआ है, error विवरणों का कार्यान्वयन एक बहुत ही सुविधाजनक उपकरण है।

इसका सिंटैक्स इसके सभी उद्देश्यों के लिए समान है - x.(T) यदि x का इंटरफ़ेस प्रकार है। x.(T) बताता है कि x nil नहीं है और x में संग्रहीत मान T के प्रकार है T अगले कुछ खंडों में, हम टाइप स्टेटमेंट्स का उपयोग करने के दो तरीके देखेंगे - एक विशिष्ट प्रकार T साथ और टाइप T के एक इंटरफेस के साथ T


(2 // आशुलिपि वाक्यविन्यास बूलियन चर ठीक लंघन
3 // आतंक: इंटरफ़ेस रूपांतरण: इंटरफ़ेस {} शून्य है, न कि स्ट्रिंग
बूलियन ओके के साथ 6 // विस्तारित सिंटैक्स
8 // घबराता नहीं है, जब बयान गलत होता है तो ठीक है
9 // अब हम सुरक्षित रूप से एक स्ट्रिंग के रूप में उपयोग कर सकते हैं)

सैंडबॉक्स: छोटा सिंटैक्स , सुरक्षित विस्तारित सिंटैक्स के साथ आतंक

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

टाइप टी अप्रूवल

प्रकार x.(T) का एक कथन x.(T) प्रकार T इंटरफ़ेस के साथ पुष्टि करता है कि x T का इंटरफ़ेस लागू करता है T इस प्रकार, आप गारंटी दे सकते हैं कि इंटरफ़ेस मूल्य इंटरफ़ेस को लागू करता है, और केवल यदि ऐसा है, तो आप इसके तरीकों का उपयोग कर सकते हैं।


(5 ... // दावा है कि x रिसॉल्वर इंटरफ़ेस को लागू करता है
6 ... // यहां हम पहले से ही सुरक्षित रूप से इस विधि का उपयोग कर सकते हैं)

यह कैसे उपयोग किया जा सकता है यह समझने के लिए, आइए pkg/errors फिर से एक नज़र डालते pkg/errors । आप इस त्रुटि पैकेज को पहले से ही जानते हैं, तो चलिए errors.Cause(err error) error में बदल देते हैं। errors.Cause(err error) error फ़ंक्शन।

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


स्रोत: pkg / त्रुटियाँ

फ़ंक्शन त्रुटि मान प्राप्त करता है, और यह नहीं मान सकता है कि गलत तर्क इसे प्राप्त करता है एक आवरण त्रुटि ( Cause विधि द्वारा समर्थित)। इसलिए, Cause विधि को कॉल करने से पहले, आपको यह सुनिश्चित करने की आवश्यकता है कि आप एक त्रुटि से निपट रहे हैं जो इस पद्धति को लागू करता है। लूप के लिए प्रत्येक पुनरावृत्ति में एक प्रकार का बयान करके, आप यह सुनिश्चित कर सकते हैं कि cause चर Cause विधि का समर्थन करता है, और जब तक आपको कोई त्रुटि नहीं मिलती है तब तक वह आंतरिक त्रुटियों को निकालना जारी रख सकता है।

केवल उन तरीकों से युक्त एक सरल स्थानीय इंटरफ़ेस बनाकर, जिसकी आपको आवश्यकता है, और उस पर जोर देते हुए, आपका कोड अन्य निर्भरताओं से अलग हो जाता है। आपके द्वारा प्राप्त तर्क में एक ज्ञात संरचना नहीं है, यह सिर्फ एक गलती है। कोई भी प्रकार जो Error और Cause विधियों को लागू करता है। इस प्रकार, यदि आप अपने त्रुटि प्रकार में Cause विधि को लागू करते हैं, तो आप इस कार्य को बिना किसी मंदी के उपयोग कर सकते हैं।

हालांकि, ध्यान में रखने के लिए एक छोटा सा दोष है: इंटरफेस परिवर्तन के अधीन हैं, इसलिए आपको सावधानीपूर्वक कोड बनाए रखना चाहिए ताकि आपके बयानों का उल्लंघन न हो। अपने इंटरफेस को परिभाषित करने के लिए मत भूलना जहां आप उनका उपयोग करते हैं, उन्हें पतला और साफ रखने के लिए, और आप ठीक हो जाएंगे।

अंत में, यदि आपको केवल एक विधि की आवश्यकता है, तो कभी-कभी अनाम इंटरफ़ेस पर एक बयान करना अधिक सुविधाजनक होता है जिसमें केवल उस विधि पर निर्भर होता है जिस पर आप भरोसा करते हैं, अर्थात् v, ok := x.(interface{ F() (int, error) }) । अनाम इंटरफ़ेस का उपयोग करने से आपके कोड को संभावित निर्भरताओं से अलग करने में मदद मिल सकती है और इसे इंटरफ़ेस में संभावित परिवर्तनों से बचा सकता है।

टाइप टी और टाइप स्विच अप्रूवल

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

पहला प्रकार अभिकथन का दूसरा संस्करण है: एक विशिष्ट प्रकार T साथ प्रकार x.(T) का एक अभिकथन किया जाता है। वह दावा करता है कि x का मान टाइप T , या इसे T टाइप किया जा सकता है T


(2 // हम v का उपयोग mypkg.SomeErrorType के रूप में कर सकते हैं)

एक अन्य प्रकार है स्विच स्विच । प्रकार स्विच आरक्षित type कीवर्ड का उपयोग करके एक प्रकार के बयान के साथ एक स्विच स्टेटमेंट को जोड़ता है। वे विशेष रूप से त्रुटि से निपटने में आम हैं, जहां एक चर त्रुटि के मूल प्रकार को जानना बहुत उपयोगी हो सकता है।


(3 // प्रसंस्करण ...
5 // प्रोसेसिंग ...)

दोनों दृष्टिकोणों का बड़ा दोष यह है कि दोनों अपनी निर्भरता के साथ कोड बाइंडिंग की ओर ले जाते हैं। दोनों उदाहरण SomeErrorType संरचना (जो स्पष्ट रूप से निर्यात की जानी चाहिए) से परिचित होना चाहिए और mypkg पैकेज को आयात करना चाहिए।
दोनों दृष्टिकोणों में, अपनी त्रुटियों को संभालते समय, आपको प्रकार से परिचित होना चाहिए और इसके पैकेज को आयात करना चाहिए। जब आप रैपर में त्रुटियों से निपटते हैं तो स्थिति बढ़ जाती है, जहां त्रुटि का कारण एक आंतरिक निर्भरता से उत्पन्न होने वाली त्रुटि हो सकती है जिसे आप नहीं जानते हैं और इसके बारे में नहीं जानना चाहिए।


(7 // प्रोसेसिंग ...
9 // प्रसंस्करण ...)

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

संक्षेप में देना

वह सब है! अब आप त्रुटियों से परिचित हैं और किसी भी त्रुटी को ठीक करने के लिए तैयार रहना चाहिए जिसे आपका गो एप्लीकेशन आपके पथ पर फेंक सकता है (या वास्तव में वापस आ सकता है)!
दोनों errors पैकेज गो में त्रुटियों के लिए सरल लेकिन महत्वपूर्ण दृष्टिकोण प्रदान करते हैं, और यदि वे आपकी आवश्यकताओं को पूरा करते हैं, तो वे एक शानदार विकल्प हैं। आप आसानी से अपनी स्वयं की त्रुटि संरचनाओं को लागू कर सकते हैं और उन्हें pkg/errors साथ जोड़कर गो त्रुटि हैंडलिंग का लाभ उठा सकते pkg/errors ।

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

आगे क्या है?

Go में त्रुटि से निपटने अब बहुत प्रासंगिक है। अब जब आपको मूल बातें मिल गई हैं, तो आप सोच रहे होंगे कि गो त्रुटियों को संभालने के लिए हमारे लिए आगे क्या है!

गो 2 का अगला संस्करण इस पर बहुत ध्यान देता है, और आप पहले से ही ड्राफ्ट संस्करण पर एक नज़र डाल सकते हैं। इसके अलावा, dotGo 2019 के दौरान , Marcel van Lojuizen ने एक ऐसे विषय पर एक उत्कृष्ट बातचीत की, जिसे मैं अभी सुझा नहीं सकता - लेकिन "GO 2 त्रुटि मान" आज ।

जाहिर है, कई और दृष्टिकोण, युक्तियां और ट्रिक्स हैं, और मैं उन सभी को एक पोस्ट में शामिल नहीं कर सकता हूं! इसके बावजूद, मुझे आशा है कि आपने इसका आनंद लिया है, और मैं आपको गेटिंग स्टार्टिंग के अगले एपिसोड में देखूंगा!

और अब पारंपरिक रूप से आपकी टिप्पणियों का इंतजार है।