प्रस्ताव: प्रयास - अंतर्निहित त्रुटि जाँच फ़ंक्शन

सारांश

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

try कंस्ट्रक्शन की व्याख्या करना आसान है, लागू करना आसान है, यह कार्यक्षमता अन्य भाषा निर्माणों के लिए रूढ़िवादी है और पूरी तरह से पिछड़ी संगत है। अगर भविष्य में हम इसे चाहते हैं तो यह भी एक्स्टेंसिबल है।

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

परिचय

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

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

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

अधिकांश फीडबैक जो हमें प्राप्त हुए हैं, वे handle डिज़ाइन के विवरण और जटिलता पर ध्यान केंद्रित करते हैं, और एक check ऑपरेटर का विचार अधिक आकर्षक निकला। वास्तव में, समुदाय के कई सदस्यों ने एक check ऑपरेटर का विचार लिया और इसका विस्तार किया। हमारे प्रस्ताव के समान कुछ पोस्ट यहां दिए गए हैं:

• ऑपरेटर के बजाय check निर्माण का उपयोग करने के लिए पहला लिखित प्रस्ताव (हमारे लिए जाना जाता है) पीटरआरके ने अपनी पोस्ट में प्रस्तावित किया था , त्रुटि से निपटने के प्रमुख भाग
• ऐसा नहीं है, # 31442 में त्रुटियों को दूर defer लिए मार्कस ने दो नए कीवर्ड, guard और मस्ट का उपयोग किया
• साथ ही pJbs ने # 32219 में निर्माण का सुझाव दिया

वर्तमान प्रस्ताव, हालांकि विस्तार में अलग है, इन तीनों पर आधारित था, और सामान्य तौर पर, पिछले साल प्रस्तावित मसौदा डिजाइन पर प्राप्त प्रतिक्रिया पर।

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

अंत में, इस प्रस्ताव के प्रकाशन के बाद, हमें पता चला कि रयान हिलमैन ने ओग रीराइट टूल का उपयोग करके पांच साल पहले try थी और इसे वास्तविक परियोजनाओं में सफलतापूर्वक इस्तेमाल किया था। देखें ( https://news.ycombinator.com/item?id=20101417 )।

अंतर्निहित कार्य फ़ंक्शन

प्रस्ताव

हमारा सुझाव है कि नए फ़ंक्शन जैसे भाषा तत्व को try और हस्ताक्षर के साथ बुलाया जाए

 func try(expr) (T1, T2, ... Tn) 

जहां expr मतलब इनपुट पैरामीटर (आमतौर पर एक फंक्शन कॉल) की अभिव्यक्ति है जो कि T1, T2, ... Tn + 1 मानों को अंतिम मान के लिए n + 1 मान लौटाता है। यदि expr एक एकल मान (n = 0) है, तो यह मान टाइप error का होना चाहिए और try कि परिणाम वापस न आए। कॉलिंग try एक अभिव्यक्ति के साथ होती है जो संकलन त्रुटि में अंतिम परिणाम प्रकार error परिणाम नहीं देता है।

try निर्माण का उपयोग केवल एक फ़ंक्शन में किया जा सकता है जो कम से कम एक मान लौटाता है, और जिसका अंतिम वापसी मान प्रकार error । अन्य संदर्भों में try को कॉल try से संकलन त्रुटि हो जाती है।

उदाहरण के रूप में f() फ़ंक्शन के साथ कॉल try करें

 x1, x2, … xn = try(f()) 

निम्नलिखित कोड की ओर जाता है:

 t1, … tn, te := f() // t1, … tn,  ()   if te != nil { err = te //  te    error return //     } x1, … xn = t1, … tn //     //     

दूसरे शब्दों में, अगर expr द्वारा लौटाए गए अंतिम error प्रकार nil , तो अंतिम nil को हटाकर, बस पहले n मान को वापस करने का try ।

यदि अंतिम मान expr द्वारा वापस नहीं किया जाता है, तो:

• एन्क्लोज़िंग फ़ंक्शन की error वापसी मान ( error नाम से ऊपर छद्म में, हालांकि यह कोई भी पहचानकर्ता या अनाम वापसी मान हो सकता है) त्रुटि मान expr से expr
• लिफ़ाफ़िंग फ़ंक्शन से बाहर निकलना है
• यदि एन्क्लोज़िंग फ़ंक्शन में अतिरिक्त रिटर्न पैरामीटर हैं, तो ये पैरामीटर उन मानों को बनाए रखते हैं जो कि try कॉल से पहले उनमें निहित थे।
• यदि एन्क्लोज़िंग फ़ंक्शन में अतिरिक्त अनाम रिटर्न पैरामीटर हैं, तो उनके लिए संबंधित शून्य मान वापस कर दिए जाते हैं (जो उनके मूल शून्य मानों को बचाने के लिए समान है, जिसके साथ वे आरंभिक होते हैं)।

यदि try कई असाइनमेंट में उपयोग किया जाता है, जैसा कि ऊपर दिए गए उदाहरण में है, और एक गैर-शून्य त्रुटि (इसके बाद नहीं-n- लगभग। प्रति।) का पता लगाया गया है, असाइनमेंट (उपयोगकर्ता चर द्वारा) नहीं किया जाता है, और असाइनमेंट के बाईं ओर कोई भी चर नहीं बदलता है। यही है, एक फ़ंक्शन कॉल की तरह व्यवहार try करें: इसके परिणाम केवल तभी उपलब्ध होते हैं जब कॉल करने वाले पर नियंत्रण की try जाती है (जैसा कि एनक्लोजिंग फ़ंक्शन से वापसी के मामले में विरोध किया जाता है)। नतीजतन, यदि असाइनमेंट के बाईं ओर के वेरिएबल्स रिटर्न पैरामीटर हैं, तो try का उपयोग try से व्यवहार में परिणाम होगा जो अब सामना किए गए विशिष्ट कोड से अलग है। उदाहरण के लिए, यदि a,b, err नाम एनक्लोजर फ़ंक्शन के रिटर्न पैरामीटर हैं, तो यह कोड है:

 a, b, err = f() if err != nil { return } 

हमेशा चरों के मानों को असाइन करेगा a, b और err , भले ही कॉल टू f() एक त्रुटि लौटाए या नहीं। विपरीत चुनौती

 a, b = try(f()) 

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

के उपयोग

try की परिभाषा आपको स्पष्ट रूप से बताती है कि इसका उपयोग कैसे करना है: बहुत सारे if अभिव्यक्ति की त्रुटि की जांच करने वाले अभिव्यक्ति को try बदला जा सकता है। उदाहरण के लिए:

 f, err := os.Open(filename) if err != nil { return …, err //       } 

को सरल बनाया जा सकता है

 f := try(os.Open(filename)) 

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

सामान्यतया, हमारा लक्ष्य एक try साथ सभी संभावित त्रुटि जांचों को बदलना नहीं है। कोड जिसे अलग-अलग शब्दार्थों की आवश्यकता होती है और त्रुटि मानों के साथ अभिव्यक्ति और स्पष्ट चर का उपयोग करना जारी रखना चाहिए।

परीक्षण और कोशिश

एक विवरण लिखने के लिए हमारे पहले के प्रयासों में (नीचे डिज़ाइन पुनरावृत्ति अनुभाग देखें), एक त्रुटि होने पर वापसी त्रुटि के बिना उपयोग किए जाने पर घबराहट की try थी। यह मानक पुस्तकालय के testing पैकेज के आधार पर इकाई परीक्षणों में try का उपयोग try की अनुमति देता है।

विकल्पों में से एक के रूप में, testing पैकेज में हस्ताक्षर के साथ परीक्षण कार्यों का उपयोग करना संभव है

 func TestXxx(*testing.T) error func BenchmarkXxx(*testing.B) error 

परीक्षणों में try के उपयोग की अनुमति देने के लिए। एक परीक्षण फ़ंक्शन जो एक t.Fatal(err) त्रुटि देता है, वह स्पष्ट रूप से t.Fatal(err) या b.Fatal(err) t.Fatal(err) कॉल करेगा। यह एक छोटा पुस्तकालय परिवर्तन है जो संदर्भ के आधार पर, try लिए विभिन्न व्यवहार (वापसी या आतंक) की आवश्यकता से बचा जाता है।

इस दृष्टिकोण की एक खामी यह है कि t.Fatal और b.Fatal उस लाइन नंबर को वापस नहीं कर पाएंगे, जिस पर परीक्षण गिर गया था। एक और नुकसान यह है कि हमें किसी तरह उप-परिवर्तन को भी बदलना होगा। इस समस्या का समाधान एक खुला प्रश्न है; हम इस दस्तावेज़ में testing पैकेज में विशिष्ट परिवर्तनों का प्रस्ताव नहीं देते हैं।

# 21111 भी देखें, जो सुझाव देता है कि उदाहरण कार्यों को एक त्रुटि वापस करने की अनुमति देता है।

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

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

यह प्रस्ताव मूल ड्राफ्ट डिजाइन को इसके सार तक कम कर देता है। यदि संवर्धन या त्रुटि रैपिंग की आवश्यकता होती है, तो दो दृष्टिकोण हैं: यदि गलत है if err != nil { return err} संलग्न करें if err != nil { return err} , या defer अभिव्यक्ति के अंदर एक त्रुटि हैंडलर की घोषणा करें:

 defer func() { if err != nil { //      -   err = … // /  } }() 

इस उदाहरण में, error एन्कोडिंग फ़ंक्शन के प्रकार की error रिटर्न पैरामीटर का नाम है।

व्यवहार में, हम इस तरह के सहायक कार्यों की कल्पना करते हैं

 func HandleErrorf(err *error, format string, args ...interface{}) { if *err != nil { *err = fmt.Errorf(format + ": %v", append(args, *err)...) } } 

या ऐसा ही कुछ। fmt पैकेज ऐसे सहायकों के लिए एक प्राकृतिक स्थान बन सकता है (यह पहले से ही fmt.Errorf प्रदान करता है)। सहायकों का उपयोग करना, एक त्रुटि हैंडलर की परिभाषा कई मामलों में एक पंक्ति में कम हो जाएगी। उदाहरण के लिए, "कॉपी" फ़ंक्शन से त्रुटि को समृद्ध करने के लिए, आप लिख सकते हैं

 defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) 

अगर fmt.HandleErrorf स्पष्ट रूप से त्रुटि जानकारी जोड़ता है। इस तरह के निर्माण को पढ़ने में काफी आसान है और इसका फायदा यह है कि इसे भाषा सिंटैक्स के नए तत्वों को जोड़े बिना लागू किया जा सकता है।

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

दक्षता में बाधा

एक त्रुटि हैंडलर के रूप में defer का उपयोग करते समय एक महत्वपूर्ण विचार दक्षता है। defer अभिव्यक्ति को धीमा माना जाता है। हम कुशल कोड और अच्छे एरर हैंडलिंग के बीच चयन नहीं करना चाहते हैं। इस प्रस्ताव के बावजूद, गो रनटाइम और कंपाइलर टीमों ने वैकल्पिक कार्यान्वयन विधियों पर चर्चा की, और हम मानते हैं कि हम मौजूदा "मैनुअल" कोड की दक्षता में तुलनीय त्रुटियों को संभालने के लिए डेफर का उपयोग करने के विशिष्ट तरीके बना सकते हैं। हमें गो 1.14 में तेजी से कार्यान्वयन को जोड़ने की उम्मीद है ( सीएल 171158 टिकट भी देखें, जो इस दिशा में पहला कदम है)।

विशेष मामले go try(f), defer try(f)

try निर्माण एक फ़ंक्शन की तरह दिखता है, और इस वजह से, यह उम्मीद की जाती है कि इसका उपयोग कहीं भी किया जा सकता है जहां फ़ंक्शन कॉल स्वीकार्य है। हालाँकि, यदि try कॉल का उपयोग go स्टेटमेंट में किया जाता है, तो चीजें जटिल हो जाती हैं:

 go try(f()) 

यहाँ f() को तब निष्पादित किया जाता है जब वर्तमान goroutine में गो एक्सप्रेशन निष्पादित किया जाता है, कॉलिंग f के परिणामों को try करने के लिए तर्क के रूप में पारित किया जाता है, जो नए गोरआउट में शुरू होता है। यदि f एक नॉनज़ेरो त्रुटि देता है, तो एन्क्लोज़िंग फ़ंक्शन से लौटने की try ; हालाँकि, कोई फ़ंक्शन नहीं है (और टाइप error का कोई रिटर्न पैरामीटर नहीं है), क्योंकि कोड को एक अलग गोरआउट में निष्पादित किया जाता है। इस वजह से, हम try कि एक बार अभिव्यक्ति में अक्षम होने का try ।

के साथ स्थिति

 defer try(f()) 

समान दिखता है, लेकिन यहां आस्थगित अर्थ का अर्थ है कि जब तक यह संलग्नक फ़ंक्शन से वापस नहीं आता, तब तक निष्पादन की try देरी होगी। पहले की तरह, f() मूल्यांकन तब किया f() है जब defer , और इसके परिणाम स्थगित try पास हो जाते हैं।

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

अंत में, बाकी बिल्ट-इन निर्माणों की तरह, try केवल कॉल के रूप में उपयोग की जा सकती है; इसका उपयोग मान फ़ंक्शन के रूप में या चर असाइनमेंट एक्सप्रेशन में f := try (जैसा कि f := print और f := new निषिद्ध है) के रूप में नहीं किया जा सकता है।

चर्चा

डिजाइन परिवर्तन

निम्नलिखित पहले के डिजाइनों की एक संक्षिप्त चर्चा है जो वर्तमान न्यूनतम प्रस्ताव का कारण बनी। हमें उम्मीद है कि यह चयनित डिजाइन निर्णयों पर प्रकाश डालेगा।

इस वाक्य की हमारी पहली पुनरावृत्ति लेख के दो विचारों से प्रेरित थी "त्रुटि के प्रमुख भागों को संभालना", अर्थात्, ऑपरेटर के बजाय अंतर्निहित फ़ंक्शन का उपयोग करना और नई भाषा के निर्माण के बजाय त्रुटियों को संभालने के लिए सामान्य गो फ़ंक्शन। उस प्रकाशन के विपरीत, हमारे त्रुटि हैंडलर के पास मामलों को सरल बनाने के लिए एक निश्चित हस्ताक्षर वाली func(error) error थी। यदि try से पहले कोई त्रुटि हुई थी, तो त्रुटि हैंडलर को फ़ंक्शन द्वारा बुलाया जाएगा, जो एन्क्लोज़िंग फ़ंक्शन से बाहर निकल जाएगा। यहाँ एक उदाहरण है:

 handler := func(err error) error { return fmt.Errorf("foo failed: %v", err) //   } f := try(os.Open(filename), handler) //      

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

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

हालांकि, प्रयास का संदर्भ-संवेदनशील व्यवहार त्रुटियों से भरा था: उदाहरण के लिए, फ़ंक्शन का उपयोग try वाला फ़ंक्शन का व्यवहार चुपचाप बदल सकता है (घबराहट या नहीं) जब फ़ंक्शन हस्ताक्षर में वापसी त्रुटि जोड़ते या निकालते हैं। यह एक संपत्ति भी खतरनाक लग रहा था। स्पष्ट समाधान यह था कि try कार्यक्षमता को दो अलग-अलग और must कार्यों में विभाजित किया जाए, ( # 31442 में जिस तरह से सुझाव दिया गया था, उसी तरह)। हालांकि, इसके लिए दो अंतर्निहित कार्यों की आवश्यकता होगी, जबकि केवल try त्रुटि से निपटने के लिए बेहतर समर्थन से सीधे संबंधित है।

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

प्रस्तावित डिजाइन की विशेषताएं

यह सुझाव काफी छोटा है और पिछले साल के मसौदे की तुलना में एक कदम पीछे लग सकता है। हम मानते हैं कि चयनित समाधान उचित हैं:

• पहले चीजें, पहले, बिना किसी handle के मूल में प्रस्तावित check स्टेटमेंट के बिल्कुल समान शब्दार्थ हैं। यह महत्वपूर्ण पहलुओं में से एक में मूल मसौदे की निष्ठा की पुष्टि करता है।

  
  

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

  
  

• ऑपरेटर के बजाय इनलाइन फ़ंक्शन का उपयोग करने के लिए कोष्ठक के उपयोग की आवश्यकता होती है। हमें try(f()) बजाय try(f()) लिखना चाहिए। यह (छोटे) मूल्य है जो हमें मौजूदा पार्सरों के साथ पिछड़ी संगतता के लिए भुगतान करना है। हालांकि, यह डिज़ाइन को भविष्य के संस्करणों के साथ भी अनुकूल बनाता है: यदि हम इस तरह से तय करते हैं कि किसी तरह से एरर हैंडलिंग फंक्शन से गुजरना या इस उद्देश्य के लिए try लिए अतिरिक्त पैरामीटर जोड़ना एक अच्छा विचार है, तो try कॉल में एक अतिरिक्त तर्क जोड़ना तुच्छ हो जाएगा।

  
  

• जैसा कि यह निकला, कोष्ठक लिखने की आवश्यकता के अपने फायदे हैं। कई try कॉल के साथ और अधिक जटिल अभिव्यक्तियों में, कोष्ठक निम्न उदाहरणों में ऑपरेटर की पूर्ववर्ती स्थिति से निपटने की आवश्यकता को समाप्त करके पठनीयता में सुधार करते हैं:

  
  

 info := try(try(os.Open(file)).Stat()) //   try info := try (try os.Open(file)).Stat() //  try   info := try (try (os.Open(file)).Stat()) //  try   

try , : try , .. try (receiver) .Stat ( os.Open ).

try , : os.Open(file) .. try ( , try os , , try try ).

, .. .

• . , . , , , .

निष्कर्ष

. , . defer , .

Go - , . , Go append . append , . , . , try .

, , Go : panic recover . error try .

, try , , — — , . Go:

• , try
• -

, , . if -.

कार्यान्वयन

:

• Go.
• try . , . .
• go/types try . .
• gccgo . ( , ).
• .

- , . , . .

Robert Griesemer go/types , () cmd/compile . , Go 1.14, 1 2019.

, Ian Lance Taylor gccgo , .

"Go 2, !" , .

1 , , , Go 1.14 .

CopyFile :

 func CopyFile(src, dst string) (err error) { defer func() { if err != nil { err = fmt.Errorf("copy %s %s: %v", src, dst, err) } }() r := try(os.Open(src)) defer r.Close() w := try(os.Create(dst)) defer func() { w.Close() if err != nil { os.Remove(dst) //    “try”    } }() try(io.Copy(w, r)) try(w.Close()) return nil } 

, " ", defer :

 defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) 

( defer -), defer , .

printSum

 func printSum(a, b string) error { x := try(strconv.Atoi(a)) y := try(strconv.Atoi(b)) fmt.Println("result:", x + y) return nil } 

:

 func printSum(a, b string) error { fmt.Println( "result:", try(strconv.Atoi(a)) + try(strconv.Atoi(b)), ) return nil } 

main :

 func localMain() error { hex := try(ioutil.ReadAll(os.Stdin)) data := try(parseHexdump(string(hex))) try(os.Stdout.Write(data)) return nil } func main() { if err := localMain(); err != nil { log.Fatal(err) } } 

- try , :

 n, err := src.Read(buf) if err == io.EOF { break } try(err) 

, .

: ?

: check handle , . , handle defer , handle .

: try ?

: try Go . - , . , . , " ". try , .. .

: try try?

: , check , must do . try , . try check (, ), - . . must ; try — . , Rust Swift try ( ). .

: ? Rust?

: Go ; , Go ( ; - ). , ? , . , , , (package, interface, if, append, recover, ...), , (struct, var, func, int, len, image, ..). Rust ? try — Go, , ( ) . , ? . , , (, ..) . . , .

: ( error) , defer , go doc. ?

: go doc , - ( _ ) , . , func f() (_ A, _ B, err error) go doc func f() (A, B, error) . , , , . , , . , , , -, (deferred) . Jonathan Geddes try() .

: defer ?

: defer . , , defer "" . . CL 171758 , defer 30%.

: ?

: , . , ( , ), . defer , . defer - https://golang.org/issue/29934 ( Go 2), .

: , try, error. , ?

: error ( ) , , nil . try . ( , . - ).

: Go , try ?

: try , try . super return -, try Go . try . .

: try , . ?

: try ; , . try ( ), . , if .

: , . try, defer . ?

: , . .

: try ( catch )?

: try — ("") , , ( ) . try ; . . "" . , . , try — . , , throw try-catch Go. , (, ), ( ) , . "" try-catch , . , , . Go . panic , .