त्रुटियों को समाप्त करके त्रुटि हैंडलिंग को मुक्त करना

Go2 का उद्देश्य त्रुटि से निपटने के ओवरहेड को कम करना है, लेकिन क्या आप जानते हैं कि त्रुटि से निपटने के लिए बेहतर सिंटैक्स से बेहतर क्या है?

त्रुटियों को संभालने की कोई आवश्यकता नहीं है। मैं नहीं कहता कि "अपनी त्रुटि से निपटने के कोड को हटाएं", इसके बजाय मैं आपके कोड को बदलने का सुझाव देता हूं ताकि आपके पास संभालने के लिए कई त्रुटियां न हों।

यह लेख जॉन ओस्टरहौट की पुस्तक " सॉफ्टवेयर डिजाइन का एक दर्शन " के "अस्तित्व से बाहर त्रुटियों" के अध्याय से प्रेरणा लेता है। मैं उनकी सलाह को गो पर लागू करने की कोशिश करूंगा।

पहला उदाहरण

यहाँ एक फ़ाइल में लाइनों की संख्या की गणना करने का कार्य है:

func CountLines(r io.Reader) (int, error) { var ( br = bufio.NewReader(r) lines int err error ) for { _, err = br.ReadString('\n') lines++ if err != nil { break } } if err != io.EOF { return 0, err } return lines, nil } 

हम bufio.Reader बनाते हैं, फिर एक पाश में बैठते हैं, ReadString पद्धति को कॉल करते हैं, काउंटर को बढ़ाते हैं जब तक हम फ़ाइल के अंत तक नहीं पहुंचते हैं, और फिर पढ़ी गई पंक्तियों की संख्या वापस करते हैं। यह वह कोड है जिसे हम लिखना चाहते थे, इसके बजाय CountLines त्रुटि से जटिल है।

उदाहरण के लिए, इस तरह का एक अजीब निर्माण है:

 _, err = br.ReadString('\n') lines++ if err != nil { break } 

हम त्रुटियों की जांच करने से पहले लाइनों की संख्या बढ़ाते हैं - यह अजीब लगता है। हमें इसे इस तरह से लिखना चाहिए क्योंकि रीडलाइन एक त्रुटि वापस कर देगा यदि यह फ़ाइल के अंत का सामना करता है - io.EOF - न्यूलाइन वर्ण को दबाने से पहले। ऐसा तब भी हो सकता है जब कोई नई रेखा न हो।

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

लेकिन हमने त्रुटियों की जाँच पूरी नहीं की है। ReadString फ़ाइल के अंत तक पहुँचने पर io.EOF को लौटा देगा। यह अपेक्षित है, ReadString को रोकने के लिए किसी तरह की आवश्यकता है, पढ़ने के लिए और कुछ नहीं है। इसलिए, CountLine के कॉलर में त्रुटि को वापस करने से पहले, हमें यह जांचने की आवश्यकता है कि क्या io.EOF त्रुटि नहीं मिली है, और इस मामले में उसे कॉलर को वापस कर दें, अन्यथा हम सब कुछ ठीक होने पर शून्य वापस आ जाएंगे। यही कारण है कि फ़ंक्शन की अंतिम पंक्ति आसान नहीं है

 return lines, err 

मुझे लगता है कि यह रस कॉक्स के अवलोकन का एक अच्छा उदाहरण है कि त्रुटि से निपटने से फ़ंक्शन अधिक कठिन हो सकता है । आइए बेहतर संस्करण देखें।

 func CountLines(r io.Reader) (int, error) { sc := bufio.NewScanner(r) lines := 0 for sc.Scan() { lines++ } return lines, sc.Err() } 

यह bufio.Reader से bufio.Scanner का उपयोग करने से संस्करण में सुधार हुआ है। हुड के अंतर्गत, bufio.Scanner bufio.Reader का उपयोग करता है, एक एब्स्ट्रेक्शन लेयर को जोड़ने से एरर हैंडलिंग को हटाने में मदद मिलती है, जो काउंटलाइन के हमारे पिछले संस्करण के काम में बाधा डालती है (bufio.Scanner किसी भी टेम्पलेट को स्कैन कर सकता है, डिफ़ॉल्ट रूप से यह नई लाइनों की खोज करता है)।

Sc.Scan () विधि सही हो जाती है यदि स्कैनर ने पाठ की एक पंक्ति पाई और कोई त्रुटि नहीं मिली। इस प्रकार, लूप के लिए हमारे शरीर को केवल तभी बुलाया जाएगा जब स्कैनर बफर में पाठ की एक पंक्ति हो। इसका मतलब यह है कि हमारे रेडलाइन काउंटलाइन मामले को सही ढंग से हैंडल करते हैं जब कोई अनुगामी न्यूलाइन वर्ण नहीं होता है। साथ ही अब मामला जब फ़ाइल खाली है तो सही तरीके से संभाला गया है।

दूसरे, चूंकि sc। कोई त्रुटि होने पर गलत हो जाता है, फ़ाइल के अंत तक पहुंचने या त्रुटि होने पर लूप के लिए हमारा अंत हो जाएगा। प्रकार bufio.Scanner पहली त्रुटि का पता चला त्रुटि को याद करता है, और हम sc.Err () पद्धति का उपयोग करके लूप से बाहर निकलने के बाद इस त्रुटि को ठीक करते हैं।

अंत में, Buffo.Scanner प्रसंस्करण io.EOF का ख्याल रखता है और अगर फ़ाइल बिना किसी त्रुटि के समाप्त हो जाती है, तो इसे शून्य में परिवर्तित कर देता है।

दूसरा उदाहरण

मेरा दूसरा उदाहरण रोब पाइक्स की त्रुटियों से प्रेरित है जो मान ब्लॉग पोस्ट हैं।

फ़ाइलें खोलने, लिखने और बंद करने के साथ काम करते समय, त्रुटि से निपटने, लेकिन बहुत प्रभावशाली नहीं है, क्योंकि संचालन ioutil.ReadFile और ioutil.WriteFile जैसे सहायकों में संपन्न हो सकता है। हालांकि, जब निम्न-स्तर के नेटवर्क प्रोटोकॉल के साथ काम करते हैं, तो अक्सर I / O प्राइमेटिव्स का उपयोग करके सीधे प्रतिक्रिया का निर्माण करना आवश्यक होता है, इसलिए त्रुटि से निपटने की पुनरावृत्ति शुरू हो सकती है। HTTP / 1.1 प्रतिक्रिया बनाने वाले HTTP सर्वर के इस टुकड़े पर विचार करें:

 type Header struct { Key, Value string } type Status struct { Code int Reason string } func WriteResponse(w io.Writer, st Status, headers []Header, body io.Reader) error { _, err := fmt.Fprintf(w, "HTTP/1.1 %d %s\r\n", st.Code, st.Reason) if err != nil { return err } for _, h := range headers { _, err := fmt.Fprintf(w, "%s: %s\r\n", h.Key, h.Value) if err != nil { return err } } if _, err := fmt.Fprint(w, "\r\n"); err != nil { return err } _, err = io.Copy(w, body) return err } 

पहले हम fmt.Fprintf का उपयोग करके एक स्थिति पट्टी बनाते हैं और एक त्रुटि की जांच करते हैं। फिर, प्रत्येक हेडर के लिए, हम हेडर की कुंजी और मूल्य रिकॉर्ड करते हैं, हर बार त्रुटि के लिए जाँच करते हैं। अंत में, हम हेडर अनुभाग को अतिरिक्त \ r \ n के साथ समाप्त करते हैं, त्रुटि की जांच करते हैं, और ग्राहक को प्रतिक्रिया निकाय की नकल करते हैं। अंत में, हालांकि हमें io.Copy से त्रुटि की जांच करने की आवश्यकता नहीं है, हमें इसे दो रिटर्न मानों के साथ फ़ॉर्म से परिवर्तित करने की आवश्यकता है, जो io.Copy सिंगल रिटर्न वैल्यू पर लिखता है जो कि WriteResponse उम्मीद करता है।

यह न केवल बहुत दोहराव वाला काम है, प्रत्येक ऑपरेशन, जो अनिवार्य रूप से io.Writer को बाइट्स लिख रहा है, त्रुटि हैंडलिंग का एक अलग रूप है। लेकिन हम एक छोटे रैपर को पेश करके अपने काम को आसान बना सकते हैं।

 type errWriter struct { io.Writer err error } func (e *errWriter) Write(buf []byte) (int, error) { if e.err != nil { return 0, e.err } var n int n, e.err = e.Writer.Write(buf) return n, nil } 

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

 func WriteResponse(w io.Writer, st Status, headers []Header, body io.Reader) error { ew := &errWriter{Writer: w} fmt.Fprintf(ew, "HTTP/1.1 %d %s\r\n", st.Code, st.Reason) for _, h := range headers { fmt.Fprintf(ew, "%s: %s\r\n", h.Key, h.Value) } fmt.Fprint(ew, "\r\n") io.Copy(ew, body) return ew.err } 

इरिट्रवेट को राइटप्रेन्स पर लागू करने से कोड स्पष्टता में सुधार होता है। प्रत्येक ऑपरेशन को अब त्रुटि जाँच के लिए सीमित करने की आवश्यकता नहीं है। त्रुटि संदेश फ़ंक्शन के अंत में जाता है, ew.err फ़ील्ड की जाँच करता है और लौटाए गए io.Copy मानों के कष्टप्रद अनुवाद से बचता है

निष्कर्ष

जब आप अत्यधिक त्रुटि से निपटने का सामना करते हैं, तो कुछ ऑपरेशन को सहायक आवरण प्रकार के रूप में निकालने का प्रयास करें।

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

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