मैं इसे अपनी सहमति देता हूँ। मुझे वास्तव में यह पसंद है कि लौटने से पहले हर त्रुटि को कैसे सजाने से स्रोत में मानव पठनीय दस्तावेज जुड़ जाते हैं (आमतौर पर हम अपनी त्रुटियों को प्रारूपित करते हैं "नहीं कर सकता [कोड की इन पंक्तियों में मैं क्या कर रहा हूं]: [पिछली त्रुटि]") और उपयोगकर्ताओं के लिए भी पढ़ने की त्रुटियां।

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

किसी भी प्रकार के संदर्भ या ट्रेसिंग के बिना त्रुटियां (नंगे स्ट्रिंग "ईओएफ") बिल्कुल बेकार हैं। मुझे लगता है कि शॉर्टकट होने से नग्न त्रुटियों को वापस करना आसान हो जाता है, जिससे गो प्रोग्राम बहुत सारी बेकार त्रुटियों को प्रिंट कर देगा।

यदि कुछ भी हो, तो हमें संदर्भ के साथ सजावटी त्रुटियों को धक्का देना चाहिए और समर्थन करना चाहिए, शायद नए पशु चिकित्सक और लिंट नियमों के साथ।

मुझे स्पष्ट रूप से त्रुटि जांच भी पसंद है। try भ्रमित करने वाला है और निहित रिटर्न अजीब है।

मुझे लगता है कि त्रुटियों पर पुनर्विचार करने के बजाय, हम इन जाँचों को छोटा करने के लिए एक वैकल्पिक दृष्टिकोण का प्रयास कर सकते हैं।

यहां एक उदाहरण दिया गया है जिससे मैं अनिवार्य रूप से सहमत नहीं हूं:

value, err := foo()
return err if err != nil

यह एक छोटे लेकिन अभी भी स्पष्ट दृष्टिकोण की अनुमति देगा। और यह संदर्भ जोड़ने की अनुमति देगा!

उस ने कहा, इनलाइन आईएफएस एक रूबी चीज है और बहुत ही गोश महसूस नहीं करते हैं, लेकिन यह सिर्फ दिमागी तूफान है। शायद हमें कुछ और मिल जाए।

संपादित करें: मैंने इसके लिए यहां एक प्रस्ताव जोड़ा: https://github.com/golang/go/issues/32860

किसी काम को करने का एक ही तरीका होना चाहिए

[...] क्यों न इसे वैसे ही रखा जाए?

मुझे लगता है कि यह कहना उचित होगा कि हम सभी इसका उत्तर जानते हैं। यदि आप ईमानदारी से नहीं जानते हैं तो आपको उत्तर जानने के लिए विभिन्न प्रस्तावों में से केवल एक को पढ़ने की आवश्यकता है।

आईएमओ, हमारे लिए एक केंद्रित चर्चा करने के लिए यहां बहुत कम विवरण है (यानी मुझे नहीं लगता कि यह एक प्रस्ताव के रूप में योग्य है) और यह जल्द ही सर्कल-झटकों और विचारों से भरा एक और बाइक-शेड में बदल जाएगा जो कोड को कम पठनीय बनाता है .

इतना ही।

यकीनन मैं इस स्पष्ट त्रुटि प्रबंधन के कारण गो में आ गया। यह निहित कोशिश-पकड़ के बीच कहीं बैठता है कि कई भाषाएं विकल्प या हो सकता है जैसे कार्य प्रकार के लिए जाती हैं, जो उपयोगकर्ता को वापस करने के पक्ष में हैं और स्पष्ट रूप से नियंत्रित की जाती हैं।

मुझे यकीन नहीं है कि कोई नया निर्माण वास्तव में इसे हल करेगा। यदि आपने if err := nil को इस तरह के एक सहायक फ़ंक्शन में लपेटा है, तो यह थोड़ी मदद कर सकता है (मेरी जंगली जाओ क्षमा करें):

func handleErr(err error, cb func(error)) {
        if err := nil {
                cb(err)
        }
}

लेकिन समस्या जो इस सहायक कार्य को कम आम तौर पर उपयोगी बनाती है वह है टाइप सिस्टम, जो एक अलग विषय है।

मैं इसे अपनी सहमति देता हूँ। if err != nil { return err } हमारे कोड बेस में किसी कोड का हिस्सा नहीं है। इसलिए "मैक्रो" की कोशिश का कोई मतलब नहीं है। संदर्भ का वर्णन करने वाले संदेश के साथ, हम केवल लिपटे त्रुटियों को वापस करते हैं।

defer के माध्यम से संदर्भ जोड़ने का भी कोई मतलब नहीं है, क्योंकि हम विभिन्न प्रकार की त्रुटियों को अलग करने के लिए विभिन्न त्रुटि संदेशों को वापस करना चाहते हैं। हालांकि try(fn(), "my error message: %w") उपयोगी हो सकता है। लेकिन फिर भी, छोटी लाइन की लंबाई के कारण if err != nil निर्माण अभी भी बेहतर हो सकता है।

सच कहूं तो, मैं एक निहित प्रतिफल नहीं चाहता जो try प्रदान करता है। अगर हमारे पास जेनेरिक होते, तो मैं ऐसे समाधान को पसंद करता जो इसके बजाय मोनैड-ईश व्यवहार का उपयोग करता।

type Result<T> interface {
  Expect(err error) T
  OrElse(defaultValue T) T
}

func From<T>(value T, err error) Result<T> { ... }

मेरे लिए, यह वर्तमान में प्रस्तावित बिल्टिन की तुलना में बहुत साफ है, हालांकि उपरोक्त में और बदलाव की आवश्यकता होगी क्योंकि आपके पास लौटाए गए तरीकों का प्रसार होगा (मूल्य, त्रुटि) और परिणाम

मौजूदा try प्रस्ताव, जिसमें त्रुटियों को स्पष्ट रूप से सजाने का कोई तरीका नहीं है, मेरी आवश्यकताओं को पूरा नहीं करता है। मैं कभी इसका उपयोग करने की कल्पना नहीं कर सकता। सच कहूँ तो, इसे code_smell भी कहा जा सकता है।

हो सकता है कि इसे बदलने का कोई मतलब न हो, क्योंकि गलत समस्या को हल करने की कोशिश की जा रही है।

जिस कोड से हम परिचित हैं, वह त्रुटि प्रबंधन नहीं है।

if err != nil {
  return err
}

यह त्रुटि nil हैंडलिंग है। इस पैटर्न में किसी भी बिंदु पर संभाली गई त्रुटि का मान नहीं है।

अगर मैं इसे एक अलग भाषा में प्रदर्शित करता, रूबी।

begin
 some_method_that_raises_an_error
rescue => e # catch any exception
  retry e        # throw it up again
end

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

गोलांग में, हम इसे return करते हैं।

वास्तविक _error हैंडलिंग_ कहां हो रहा है?

हम सभी को इस पैटर्न की विफलता के समान अनुभव हुए हैं। उदाहरण के लिए, एक file not found त्रुटि प्राप्त करना और फिर इस त्रुटि के मूल _थ्रोवर_ को ट्रेस करने में काफी समय व्यतीत करना।

यही कारण है कि मेरा मानना ​​है कि try प्रस्ताव (और अन्य) दोषपूर्ण हैं। वास्तव में त्रुटियों को संभालने के लिए हमारे पास एक अच्छा पैटर्न नहीं है।

मैंने वास्तव में त्रुटि का निरीक्षण करने के लिए err.Error() स्ट्रिंग जाँच, प्रकार के दावे आदि देखे हैं।
हमें इस असंगति के लिए एक पैटर्न की आवश्यकता है। ऐसा लगता है कि xerrs इसे हल कर रहा है, लेकिन यह भी अभी तक पूरा नहीं हुआ है।

मैं ग़लती रखने का समर्थन करता हूँ!=शून्य यथास्थिति की जाँच करें।

हर बार जब मैं एक बड़े गो कोड बेस में खोदता हूं तो मैं खुद से पूछता हूं कि मैं कुछ बॉयलरप्लेट को कैसे कम कर सकता हूं। मैं हमेशा यहां वापस आता हूं:

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

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

अगर मैं कर सकता हूं, तो मुझे विश्वास है कि यह उत्तर है। यह नया त्रुटि प्रस्ताव भाषा के लक्ष्यों के सीधे विरोध में है।

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

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

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

अधिक सहमत नहीं हो सका। स्पष्ट त्रुटि प्रबंधन IMO भाषा की सर्वोत्तम विशेषताओं में से एक है। मुझे हमेशा ऐसा लगता है कि जो लोग इससे परेशान हैं, वे अभी इसके अभ्यस्त नहीं हैं।

मुद्दों को अलग करना अच्छा नहीं है, लेकिन मैं सोच रहा हूं कि इस मामले में दो राय एक राय के रूप में विलीन हो गई हैं।

1. हमें नया सिंटैक्स पसंद नहीं है (कोशिश करें या नया if-err सिंटैक्स)
2. वैसे भी, हम नया सिंटैक्स नहीं जोड़ना चाहते हैं

गिटहब वोट आइकन दूसरे की व्याख्या नहीं कर सकते हैं।

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

मैंने #32811 लिखा है और मैं इस प्रस्ताव का अधिक समर्थन करता हूं... मैं इसके बजाय केवल त्रुटि प्रबंधन को ही छोड़ दूंगा। मुझे लगता है कि इस प्रस्ताव पर इमोजी की प्रतिक्रियाएं बहुत कुछ कहती हैं।

मैं व्यक्तिगत रूप से इस बात से सहमत हूं कि गलती से निपटने को वैसे ही छोड़ दें। गो के बारे में मुझे जो चीजें पसंद हैं उनमें से एक यह है कि भाषा न्यूनतम है, और आम तौर पर बोलने का एक तरीका होता है। त्रुटि प्रबंधन के लिए नया सिंटैक्स जोड़कर, हम एक ऐसी दुनिया बनाएंगे जहां x% कोड वर्तमान पद्धति का उपयोग करता है, और y% नई विधि का उपयोग करता है। यह, पहले से चर्चा किए गए अन्य मुद्दों के अलावा, असंगत कोड आधार बनाएगा। मैं व्यक्तिगत रूप से नहीं सोचता कि नई त्रुटि प्रबंधन वाक्यविन्यास का मूल्य व्यापार बंद के लायक है, क्योंकि मैं मौजूदा वाक्यविन्यास को पर्याप्त/पर्याप्त मानता हूं।

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

return ... if ...ˋ @andreynering का सुझाव वास्तव में काफी स्मार्ट

सहमत, if err != nil अकेला छोड़ दें।

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

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

कृपया, केवल चीजों को जोड़ने के लिए चीजों को न जोड़ें।

मैं त्रुटि प्रबंधन की सादगी का आनंद लेता हूं।

अपेक्षा केवल एक विपर्यय है सिवाय इसके लिए, और मैं इसका उपयोग नहीं करना चाहूंगा। इसे शुरू करने के लिए धन्यवाद।

कृपया मेरी पवित्र कब्र को मत बदलो।

अधिक सुव्यवस्थित त्रुटि प्रबंधन (वार्षिक सर्वेक्षण से) का अनुरोध करने वाली भारी सामुदायिक प्रतिक्रिया थी। गो टीम अब उस मुद्दे को संबोधित कर रही है।

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

एक शिकायत इसे टाइप करने की थी, लेकिन वस्तुतः हर संपादक के पास कोड स्निपेट डालने के लिए शॉर्टकट होते हैं, इसलिए यह वास्तव में कोई बड़ी बात नहीं है। शायद यह मेरा अपना अनुभव है कि मैं 1.0 से पहले से गो का उपयोग कर रहा हूं, लेकिन मुझे सादगी पसंद है और मुझे अतिरेक की परवाह नहीं है।

@kevineaton आपको लगता है कि try जटिल है?

मैं पूरी तरह से इस बात से सहमत हूं। मैं व्यक्तिगत रूप से भी आश्वस्त नहीं हूं कि हमें कुछ भी करने की आवश्यकता है - मैं मानता हूं कि if err != nil चेक पहले ब्लश पर अजीब लगते हैं लेकिन मैंने ऐसा कुछ भी प्रस्तावित नहीं देखा है जो वास्तव में उन चीजों का उल्लंघन किए बिना इस मुद्दे को हल करता है जो कि है के लिए लोकप्रिय है।

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

इश्यू ट्रैकर कई चीजों के लिए उपयोगी है, लेकिन एक चीज जिसके लिए यह उपयोगी नहीं है, वह है एक जटिल विषय की विस्तृत चर्चा।

सच नहीं है। लेकिन हम यहाँ हैं।

यदि try जोड़ दिया जाए तो if err != nil नहीं जाएगा। मेरा मानना ​​है कि try कोड पथों में कुछ स्पष्टता जोड़ देगा जो या तो भारी अग्रेषण त्रुटि हैं या जहां एक विलंब त्रुटि हैंडलर में कई अलग-अलग त्रुटियों को आसान बनाया जा सकता है। . मैं वास्तव में नहीं देखता कि कैसे try त्रुटियों को संभालने के लिए प्रोत्साहित नहीं करता है जो खाली if-err-return-err समूह से कहीं अधिक है। try मौजूद है या नहीं, इसकी परवाह किए बिना वास्तव में त्रुटियों को संभालने की उपेक्षा करना आसान है। मुझे लगता है कि try त्रुटि प्रबंधन के लिए अभी तक के सर्वोत्तम सुझावों में से एक है क्योंकि ऐसा लगता है कि इसका उपयोग करने वाले कोड को पढ़ना आसान होगा ..

मेरे अवांछित दो सेंट, यह बहुत "जाओ" की तरह महसूस नहीं करता है। यह बहुत ही जादुई है और हम स्पष्ट लोगों पर निहित निर्माण के लिए जा रहे हैं।

गो से अक्सर पूछे जाने

गो के पास ?: ऑपरेटर क्यों नहीं है?
_Go में कोई टर्नरी टेस्टिंग ऑपरेशन नहीं है। आप समान परिणाम प्राप्त करने के लिए निम्नलिखित का उपयोग कर सकते हैं:_

if expr {
   n = trueVal
} else {
    n = falseVal
}

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

@ianlancetaylor

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

आप किसी विशिष्ट संदेश का उत्तर दे सकते हैं। मैंने अभी तुम्हारा जवाब दिया। :)

चूंकि यहां कोई वास्तविक प्रस्ताव नहीं है, बस अन्य प्रस्तावों की प्रतिक्रिया है,

मेरे लिए एक प्रस्ताव का अर्थ है परिवर्तन का आह्वान। यह विशेष मुद्दा परिवर्तन विरोधी है। क्या आप प्रस्ताव करते हैं कि हम त्रुटि प्रबंधन को _not_ बदलने के लिए एक प्रस्ताव तैयार करें? मुझे लगता है कि प्रस्ताव प्रणाली बहुत अच्छी है लेकिन यह यथास्थिति को कम प्रतिनिधित्व देती है।

जावा और पायथन लिखने में दस साल बिताने के बाद ... मैं एक सॉफ्टवेयर आर्किटेक्ट के रूप में अपने दिन-प्रतिदिन के काम के शीर्ष पर कंप्यूटर विज्ञान भी पढ़ाता हूं

@kevineaton क्या आप अपना खुद का डिक

यह मुद्दा एक अर्ध-आधिकारिक स्थान पर लंबे समय से चल रहे मतदान के रूप में कार्य करता है, जहां मूल रूप से कोई भी आसानी से प्रस्तावों के पक्ष या विपक्ष में मतदान कर सकता है।

if err != nil को हटाने के लिए भाषा नहीं बदलना एक पूरी तरह से जटिल प्रस्ताव है जिसमें मूल रूप से कोई अतिरिक्त विवरण की आवश्यकता नहीं है। मुझे यकीन नहीं है कि समस्या क्या है। नहीं, यह भगवान बहुत लंबा और टटोलना कठिन नहीं है। यह इसे गलत या बुरा या अपर्याप्त नहीं बनाता है।

+1, अगर कुछ भी बेहतर नहीं है, तो अच्छी बात वास्तव में एक अच्छी स्टैकट्रैक जानकारी होगी (फ्रेम नृत्य सामग्री के बिना), मुझे लगता है कि x/errors पहले से ही इसे हासिल कर चुका है, लेकिन, मुझे निकट भविष्य में कुछ तेज पसंद आएगा, जैसे अंकन func s throws कीवर्ड का उपयोग करके जो एक error + try कीवर्ड लौटाएगा, त्रुटि var शैडोइंग को रोकना (जिसे मैं व्यक्तिगत रूप से नफरत करता हूं), कुछ इस तरह:

func a() (int) throws {
  throw &someError{}
}

anInt, err := try a()

@icholi वह अविश्वसनीय रूप से अवांछित था। यह चर्चा का स्थान है और गो समुदाय को स्वागत करने वाला समुदाय माना जाता है। इस तरह की टिप्पणी के लिए कोई जगह नहीं है। मेरा मानना ​​है कि सुकरात को एक बहस में अपमान के बारे में कुछ कहना था।

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

@kevineaton आपको लगता है कि try जटिल है?

try एक कोड गंध है। यह केवल एक स्थान के बजाय आपके कोड के पूरे ब्लॉक के बीच इंडेंटेशन को बाध्य करता है। इसके अलावा अपवाद से निपटने की "बबल-अप" प्रकृति कोड और कई निकास बिंदुओं में वास्तविक गैर-निर्धारिती व्यवहार बनाती है।

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

try ब्लॉक कई रिटर्न के पूरे कमबख्त उद्देश्य को हरा देते हैं।

@fillest हालांकि यह कोड को थोड़ा कम पठनीय बना देगा, मुझे लगता है कि यह सुरक्षा/स्पष्ट त्रुटि प्रबंधन के मामले में एक मूल्य जोड़ होगा। यदि आप मूल लक्ष्यों को देखते हैं कि हम गो में त्रुटियों को कैसे संभालते हैं, तो मुझे लगता है कि स्पष्ट रूप से अच्छा होने की भावना का पीछा करते हुए आपके द्वारा उद्धृत बग के वर्ग से बचने के लिए यह एक अच्छा पुनरावृत्ति होगा।

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

@fillest त्रुटि प्रबंधन में प्रस्तावित परिवर्तन "लेग-शूटिंग" को आसान बनाता है और त्रुटियां अधिक स्पष्ट होती हैं क्योंकि उन्हें आलसी रूप से नियंत्रित किया जा सकता है।

मैंने जेनरिक की कमी, बॉयलरप्लेट प्रवृत्ति, जीसी, संसाधन सीमा/लेखा की कमी और PHP noobs से उत्पन्न कार्यभार की कमी के कारण गो का उपयोग करना बंद कर दिया, जो समझ में नहीं आया कि एक कंपाइलर क्या करता है। हास्केल, सी # और अन्य ने त्रुटि को बहुत अच्छी तरह से हल किया ... गो 2 प्रस्ताव ठीक दिखता है यदि इसमें पहले (अनिश्चित) के रूप में स्पष्ट केस हैंडलिंग है।

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

पूरी तरह से सहमत हैं, क्योंकि try बिल्टिन त्रुटियों को लपेटने और थोड़ी देर के लिए भी उनमें जानकारी जोड़ने में मदद नहीं करेगा।

try साथ फिर से लिखने से पहले:

_, err := doSomething()
if err != nil {
    return nil, errors.Wrap(err, "failed to do something")
}

_, err = doOtherThing()
if err != nil {
  return nil, errors.Wrap("failed to do the other thing")
}

कल्पना कीजिए कि try साथ फिर से लिखने के बाद क्या होगा।

चूंकि try पहले से ही कोष्ठक में अपने तर्क को संलग्न करके 1-तर्क फ़ंक्शन की तरह कार्य करता है, यह दूसरा तर्क स्वीकार कर सकता है जो त्रुटि रैपिंग कोड है।

try(extract_value(try(get_data(1), errors.Wrap(err, "failed to get data")), errors.Wrap(err, "failed to get data")))

जहां err मूल्य को निहित रूप से पेश करना होगा (एक स्वच्छ तरीके से)। फिर यदि try को 1-तर्क फ़ंक्शन के रूप में उपयोग किया जाता है तो यह अपनी त्रुटि को अपरिवर्तित कर देगा।

मैं सहमत हूं, केवल "वाक्यविन्यास चीनी" चीज जो त्रुटि को थोड़ा आसान बना सकती है, हमें निम्न की तरह कुछ करने दे रही है जब हमारे कार्यों से कई रिटर्न होते हैं ... अंडरस्कोर केवल रिटर्न प्रकार के डिफ़ॉल्ट मान होंगे

if err != nil {
    return _, _, err
}

@sorenvonsarvort यह मेरे लिए उतना बुरा नहीं लगता:

var errContext string 

defer func() {
  // err is a named return
  if err != nil {
    err = fmt.Errorf("%v: %w", errContext, err)
  }
}()

errContext = "failed to do something"
_ := try(doSomething())

errContext = "failed to do other thing"
_ := try(doOtherThing())

मेरी समझ से, आप अभी भी if err != nil { ... } उपयोग कर सकते हैं यदि यह कोड के उस विशेष खंड के लिए स्पष्ट है।

try अन्य मामलों में चमकता है। कुछ और कल्पना कीजिए:

func trySomeComplexOp() (r result, err error) {
  a := try(step1())
  b := try(step2(a))
  c, d := try(step3(b))
  return try(lastStep(c, d)), nil
}

उपरोक्त कोड जैसा कोड आपको if err != nil ब्लॉक में छिड़कने की तुलना में बहुत साफ हो सकता है। गो "रैखिक पठनीयता" के बारे में है, इसलिए मुझे लगता है कि try उस छोर की ओर अच्छा करता है।

अधिक सुव्यवस्थित त्रुटि प्रबंधन (वार्षिक सर्वेक्षण से) का अनुरोध करने वाली भारी सामुदायिक प्रतिक्रिया थी। गो टीम अब उस मुद्दे को संबोधित कर रही है।

यह एक मुखर अल्पसंख्यक है और मैं शर्त लगाता हूं कि उनमें से एक अच्छा हिस्सा गो का उपयोग भी नहीं करता है

@sirkon आप उस कथन को किस पर आधारित कर रहे हैं?

@sorenvonsarvort यह मेरे लिए उतना बुरा नहीं लगता:

उपरोक्त कोड जैसा कोड आपको if err != nil ब्लॉक में छिड़कने की तुलना में बहुत साफ हो सकता है। गो "रैखिक पठनीयता" के बारे में है, इसलिए मुझे लगता है कि try उस छोर की ओर अच्छा करता है।

रूस में हम इसे «экономия на спичках» कहते हैं। अर्थ प्राप्त करने के लिए Google अनुवाद का प्रयोग करें।

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

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

मुझे यह पसंद है कि try मूल रूप से एक शॉर्टकट है और कुछ बॉयलरप्लेट कोड को कम करता है। लेकिन हम अतिरिक्त जानकारी के साथ त्रुटियों को लपेटने की क्षमता खो देते हैं। हालाँकि, निम्न परिवर्तन इसे ठीक कर सकता है:

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

हो जाता है

f := try(os.Open(filename), "open data file")

बेशक, यदि आपको इससे अधिक करने की आवश्यकता है, तो err != nil चेक करने का "पूर्ण" तरीका अभी भी उपलब्ध है।

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

लेकिन परिवर्तन के साथ मेरा प्रारंभिक अनुभव इस बात का समर्थन करता प्रतीत होता है कि यह वास्तव में अनावश्यक है। मेरे पास 2 "वास्तविक दुनिया" कार्यक्रम हैं जिनमें से प्रत्येक में लगभग 10k लाइनें हैं और दोनों पर चल रहे ट्राइहार्ड से पता चलता है कि उनमें से कोई भी इस बदलाव से लाभान्वित नहीं होगा। यह इस तथ्य से आसानी से समझाया गया है कि दोनों हमेशा त्रुटियों के संदर्भ को जोड़ते हैं। मेरे पास गो में अन्य छोटे "खिलौना" कार्यक्रम हैं और tryhard को 1 मामला मिला जहां मैं उनमें से एक में try का उपयोग कर सकता था, लेकिन बस इतना ही।

मैं मानता हूं कि अन्य लोग मुझसे अलग तरह से त्रुटियों का इलाज कर सकते हैं और मैं इस संभावना को स्वीकार करता हूं कि try सकारात्मक तरीके से उपयोग किया जा सकता है। tryhard स्रोत कोड में return err लगातार कुछ मामले हैं, कि अगर इसे try का उपयोग करना था, तो मुझे नहीं लगता कि सुगमता से इतना समझौता किया जाएगा। लेकिन मुझे सिर्फ दुरुपयोग का डर है, क्योंकि वे पठनीयता को प्रभावित करेंगे। एक अच्छा उदाहरण यहां दिया गया है । और फिर यह निर्धारित करना कि क्या अच्छा उपयोग है या नहीं, एक पूरी कहानी होगी।

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

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

अधिक सुव्यवस्थित त्रुटि प्रबंधन (वार्षिक सर्वेक्षण से) का अनुरोध करने वाली भारी सामुदायिक प्रतिक्रिया थी। गो टीम अब उस मुद्दे को संबोधित कर रही है।

@icholy जैसा मैंने कहा, मैं त्रुटियों के लिए संदर्भ जोड़ना पसंद करता हूं। उस संबंध में, मेरे लिए "अधिक सुव्यवस्थित त्रुटि प्रबंधन" का अर्थ उस संदर्भ को प्रदान करने और उससे जानकारी प्राप्त करने के बेहतर तरीके हैं। उदाहरण के लिए, मैंने अपनी त्रुटियों में जोड़े गए सभी संदर्भों के साथ "संदर्भ" पूछने के लिए छोटा होना चाहिए यदि त्रुटि टाइमआउट के कारण हुई थी। लेकिन ऐसा नहीं है। आपको आमतौर पर उपयोग करने का सहारा लेना पड़ता है pkg/error , अपनी खुद की "त्रुटि संरचनाएं" बनाएं और/या उनके साथ काम करने के तरीके बनाएं जो कार्यान्वयन के आधार पर स्ट्रिंग खोजों का सहारा ले सकते हैं। मैं कुछ ऐसा देखना चाहता हूं जो मुझे उन चीजों की तुलना में पूरी संरचना और विधियों को बनाने से बचाएगा जो मुझे कभी-कभी सबसे अच्छा if बचाते हैं। और जैसा कि पहले कहा गया था, क्या आप वास्तव में इसे "त्रुटि प्रबंधन" कह सकते हैं जब यह परिवर्तन मूल रूप से त्रुटि को वास्तव में संभालने के लिए एक अधिक सुविधाजनक तरीका प्रदान नहीं कर रहा है?

आपको लगता है कि try जटिल है?

अलगाव में try जटिल नहीं है, लेकिन भाषा परिवर्तन अलगाव में नहीं माना जाता है। विचार करना:

• एक नए बिलिन के शब्दार्थ सीखने से संज्ञानात्मक भार में वृद्धि
• try उपयोग के कारण पठनीयता में कमी क्योंकि यह कम है, ऐसे मामलों में जहां इसके बजाय if err != nil {return ... errors.Wrap() } उपयोग किया जाना चाहिए था

मैं उपरोक्त भावनाओं को प्रतिध्वनित करता हूं कि त्रुटियों की जांच करने के लिए एक संक्षिप्त तरीके से सरलता (त्रुटियों की जांच करने का एक ही तरीका है) अधिक महत्वपूर्ण है।

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

मुझे try प्रस्ताव में कोई समस्या नहीं दिख रही है?
यदि आप पुराने व्यवहार का उपयोग करना चाहते हैं या किसी अन्य तरीके से त्रुटि को संभालना चाहते हैं, तो पुराने तरीके का पुन: उपयोग क्यों न करें? कोई भी आपकी गर्दन पर चाकू चिपकाकर नहीं दबाता है आप try सिंटैक्स का उपयोग करते हैं?
try सिंटैक्स सरल है, और बॉयलरप्लेट कोड को कम करने का एक सुंदर तरीका है, मुझे नहीं पता कि गोफर को सैडिज्म-वे क्यों पसंद है?

क्या होगा अगर gofmt को इस तरह बदल दिया जाए कि एक-स्टेटमेंट अगर ब्लॉक एक लाइन पर रहे?

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

यहाँ यह कैसा दिखेगा:

// we already have an err in scope
err = frub.Confozzle(foo, bar, baz)
if err != nil { return errors.Wrap(err, "confozzling didn't work") }

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

त्रुटि रैपिंग और स्टैक फ्रेम/त्रुटि मुद्रण सामग्री बहुत अधिक सीधे आगे बढ़ेगी। मुझे लगता है कि इसके लिए समय पर एक अच्छा समाधान होगा, लेकिन अभी नहीं।

मैं इसे ऐसे ही छोड़ने से पूरी तरह सहमत हूं। यह थोड़ा बहुत वर्बोज़ है लेकिन इसका अनुसरण करना बहुत सीधा है।

अगर मैं बस कम कर सकता

if err := foo.x(a, b); err != nil {
    return err
}

if err := foo.y(); err != nil {
    return err
}

if err := foo.z(c); err != nil {
    return err
}

कुछ ऐसा करने के लिए

if err := check foo.x(a, b), foo.y(), foo.z(c); err != nil {
    return err
}

शायद मुहावरे को बहुत ज्यादा IMHO बदले बिना भी अच्छा होगा।

@henvic मुझे लगता है कि इसके साथ समस्या यह है कि आप मान रहे हैं कि आप तीन त्रुटियों को उसी तरह संभालना चाहते हैं। गो आपको प्रत्येक त्रुटि को व्यक्तिगत रूप से संभालने के तरीके के बारे में सोचने के लिए मजबूर करता है। अलग त्रुटि जाँच होने से यह स्पष्ट हो जाता है। उन्हें एक में एकत्रित करने से देव को संज्ञानात्मक रूप से वापस जाना पड़ता है और जांचना पड़ता है, क्या इन त्रुटियों को _वास्तव में उसी तरह से व्यवहार किया जाना चाहिए? मुझे लगता है कि इस प्रस्ताव के साथ हम कुछ कम महत्वपूर्ण स्ट्रोक के लिए स्पष्टता खो देते हैं और त्रुटियों के बारे में सोचने पर मजबूर कर देते हैं।

@sanbornm , तुम सही हो। मैं सहमत हूं।

यह check भी एक checkNonZero ऑपरेटर हो सकता है जो केवल एक वापसी तर्क लेगा और पहले गैर-शून्य मान (जैसे शून्य) पर वापस आ जाएगा। लेकिन बहुत अस्पष्ट होने के अलावा, और भाषा को और भी अधिक प्रभावित कर रहा है। यह केवल थोड़ा सा संकेत देगा कि यदि आप उम्मीद कर रहे हैं, तो io.EOF का उपयोग नहीं करना चाहिए। एक और संभावना होगी, शायद, go vet पर भरोसा करने के लिए कम से कम आपको सबसे आम मामलों के बारे में बताएं (जैसे io.EOF पाइप से पढ़ते समय) ... लेकिन यह विचार अच्छा नहीं लगता है सब मुझे।

मुझे try प्रस्ताव में कोई समस्या नहीं दिख रही है?
यदि आप पुराने व्यवहार का उपयोग करना चाहते हैं या किसी अन्य तरीके से त्रुटि को संभालना चाहते हैं, तो पुराने तरीके का पुन: उपयोग क्यों न करें? कोई भी आपकी गर्दन पर चाकू चिपकाकर नहीं दबाता है आप try सिंटैक्स का उपयोग करते हैं?
try सिंटैक्स सरल है, और बॉयलरप्लेट कोड को कम करने का एक सुंदर तरीका है, मुझे नहीं पता कि गोफर को सैडिज्म-वे क्यों पसंद है?

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

बड़ी परियोजनाओं में, सबसे खराब लॉग एक फ़ंक्शन द्वारा उत्पन्न होते हैं जिसे हम भूल गए किसी ने लिखा था, जो एक पुस्तकालय को कॉल करता है जो एक पुस्तकालय को कॉल करता है जो एक सामान्य new Exception() फेंकता है जो कि "पोकेमॉन" अपवाद हैंडलर तक कुछ भी नहीं पकड़ा जाता है और एक सामान्य त्रुटि लॉग की। दूसरा सबसे खराब वही है, लेकिन एक अचूक कई-सौ-लाइन स्टैक ट्रेस के साथ, जिसके साथ मुझे लगता है कि हम अंततः कारण का पता लगा सकते हैं (सौभाग्य से केवल github.com/<us>/<ourproject> खोज में अधिकांश प्रासंगिक जानकारी मिलती है, लेकिन कभी-कभी बहुत कुछ होता है)। उनके नाम के बावजूद, "अपवाद" बड़ी जावा परियोजनाओं में चिंताजनक रूप से असाधारण हैं।

इस बीच, यहां तक ​​​​कि जब बहुत सारे निरर्थक संदर्भ होते हैं, तो "narf: Error unpoiting the zort: foo: Unexpected bar in baz: {\"ork\": \"morpork\"}" जैसे सरल गो त्रुटि स्ट्रिंग्स (मेरे अनुभव में) आमतौर पर व्याख्या करना बहुत आसान होता है, जब तक कि हम कहीं भी महत्वपूर्ण संदर्भ को एम्बेड करने के बारे में मेहनती रहे हैं। वास्तविक त्रुटि मान। यदि महत्वपूर्ण संदर्भ गायब हो जाता है, तो यह _भी_ आमतौर पर काफी स्पष्ट है। उन मामलों में "फिक्स" अधिक संदर्भ जोड़ रहा है और एक और त्रुटि की प्रतीक्षा कर रहा है, इसलिए यह सही नहीं है, लेकिन संतुलन पर मैं अभी भी स्टैक ट्रेस के माध्यम से स्क्रॉल करना पसंद करता हूं और/या मेरी निर्भरताओं की निर्भरताओं की निर्भरताओं पर निर्भर करता हूं "फेंकने के लिए " या "उठाएं" समझदार त्रुटि संदेश। मैं वास्तव में सराहना करता हूं कि कैसे नाम panic() अधिकांश गो डेवलपर्स को इतनी उदारतापूर्वक तैनात करने से रोकता है जो अनिवार्य रूप से एक ही भाषा सुविधा है। आइए error और panic को एक ही चीज़ न बनाएं।

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

func foo(a, b, c SomeArgType) (x, y, z SomeReturnType, err error) {
  handleError := func(handleErr error) (x, y, z SomeReturnType, err error) {
    log.WithFields(logrus.Fields{
      "package": "foo",
      "func": "foo",
      "arguments": map[string]SomeArgType{"a": a, "b": b, "c": c},
      "error": handleErr,
    }).Error("Error fooing the bar")
    return reasonable, default, values, handleErr
  }

  err := doABunchOfThings()
  if err != nil {
    return handleError(err)
  }
}

जो, माना जाता है, कुछ मायनों में _अभी भी एक अपूर्ण समाधान है। लेकिन मुझे यह पसंद है कि ऐसा करने से भविष्य के डेवलपर्स के लिए यह समझना बहुत आसान हो गया कि foo कब और क्या लौटाता है, बिना नियंत्रण प्रवाह के बहुत अधिक उछलता है।

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

@ थॉमसफ

त्रुटि रैपिंग और स्टैक फ्रेम/त्रुटि मुद्रण सामग्री बहुत अधिक सीधे आगे बढ़ेगी

मैं सहमत हूं।

व्यक्तिगत रूप से मैं अधिक शक्तिशाली go2 सुविधाओं को शुरू करने के साथ इंतजार करना पसंद करूंगा जब तक कि पैरामीट्रिक बहुरूपता का निपटारा न हो जाए क्योंकि यह बाकी सुविधाओं को डिजाइन करते समय संभावित रूप से उपयोगी हो सकता है।

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

@इचोली

अधिक सुव्यवस्थित त्रुटि प्रबंधन (वार्षिक सर्वेक्षण से) का अनुरोध करने वाली भारी सामुदायिक प्रतिक्रिया थी। गो टीम अब उस मुद्दे को संबोधित कर रही है।

बस इसका जवाब देने के लिए; ब्रिटेन में भी ब्रेक्सिट के पक्ष में बहुमत था। ज़रूर, यूरोपीय संघ कुछ नुकसान भी लाता है जिसका आम जनता ने जवाब दिया। हालाँकि, एक बार जब सभी विकल्प सामने आ गए, तो ऐसा लग रहा था कि यूरोपीय संघ में रहना इतना बुरा नहीं होगा।

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

त्रुटि प्रबंधन के बारे में मेरा दृढ़ मत नहीं है, लेकिन यह चीजों को वैसे ही छोड़ने का तर्क हो सकता है जैसे वे हैं।

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

@इचोली

अधिक सुव्यवस्थित त्रुटि प्रबंधन (वार्षिक सर्वेक्षण से) का अनुरोध करने वाली भारी सामुदायिक प्रतिक्रिया थी। गो टीम अब उस मुद्दे को संबोधित कर रही है।

बस इसका जवाब देने के लिए; ब्रिटेन में भी ब्रेक्सिट के पक्ष में बहुमत था। ज़रूर, यूरोपीय संघ कुछ नुकसान भी लाता है जिसका आम जनता ने जवाब दिया। हालाँकि, एक बार जब सभी विकल्प सामने आ गए, तो ऐसा लग रहा था कि यूरोपीय संघ में रहना इतना बुरा नहीं होगा।

आपको इस व्यक्ति के दावे पर गंभीरता से विचार करने की आवश्यकता नहीं है: इमोजी की गिनती से पता चलता है कि लोग आमतौर पर try प्रस्ताव को पसंद नहीं करते हैं और वे आम तौर पर इसे "इसे वैसे ही रहने दें" पसंद करते हैं।

मेरे व्यवहार में पीएस, जो लोग इसके मुख्य डोमेन (नेटवर्क सेवाओं, सीएलआई उपयोगिताओं) में गो को नापसंद करते हैं, उन्होंने इसका उपयोग भी नहीं किया है। इसलिए मैं उनकी राय को नजरअंदाज करना पसंद करूंगा।

हमें try प्रस्ताव की तुलना में बेहतर, कम विवादास्पद, विकल्पों की आवश्यकता है।
मुझे जल्दबाजी में समाधान की आवश्यकता नहीं दिखती।

@velovix मुझे लगता है कि मैं कोशिश/पकड़ त्रुटि "हैंडलिंग" से अधिक पैरामीट्रिक बहुरूपता से नफरत करता हूं, लेकिन अगर यह एक भाषा सुविधा बन जाती है, तो मैं कुछ तरीकों को देख सकता हूं जो इसे एक और अंतर्निहित भाषा सुविधा की आवश्यकता को दूर कर देगा।

एक बात के लिए, जब लोग जिस कोड को दोहराना नहीं चाहते हैं वह बॉयलरप्लेट है जैसे:

foo, err := Foo()
if err != nil {
  log(err)
}
bar, err := Bar(foo)
if err != nil {
  log(err)
}
// ...

फिर पैरामीट्रिक फ़ंक्शंस के कुछ संयोजन, अनुमान टाइप करें, और _maybe_ या _Optional_ स्टाइल ऑब्जेक्ट डिज़ाइन पैटर्न अजीब गैर-रैखिक नियंत्रण प्रवाह रणनीतियों का सहारा लिए बिना बॉयलरप्लेट को सीधे (हे) कम कर देंगे:

func<T> DoWithErrorLogging(f func(any...) (T, error), args... any) T {
  t, err := f(args...)
  if err != nil {
    log(err)
  }
  return t
}
// ...
foo := DoWithErrorLogging(Foo)
bar := DoWithErrorLogging(Bar, foo)

आईएमओ यह सब गो 1 से कहीं ज्यादा खराब होगा। लेकिन भाषा में यह _plus_ कोशिश/पकड़ने वाले कीवर्ड रखने से बेहतर है।

ईमानदारी से... जैसा कि चीजें अभी खड़ी हैं, मुझे लगता है कि Go2 के लिए मेरे पसंदीदा "ब्रेकिंग" परिवर्तन Go1 में सभी छोटी असुविधाओं को ठीक कर देंगे, जैसे कि net/http डिफॉल्ट्स म्यूटेबल शेयर्ड ग्लोबल्स हैं जो म्यूटेबल शेयर्ड ग्लोबल्स के अंदर नेस्टेड हैं (बस हाशिकॉर्प के cleanhttp मानक, मूल रूप से), या (*time.Timer).Reset() को एक बेकार वापसी मूल्य बनाएं , जिसके बारे में आपको अभी पता होना चाहिए, या

मैं try ... के पक्ष में हूं जब संयम से उपयोग किया जाता है। मुझे संदेह है कि लोकप्रिय परियोजनाएं प्रयास के उपयोग के साथ ठीक होने पर दिशानिर्देश जोड़ देंगी, और छोटी/नई/एकल-व्यक्ति परियोजनाएं कभी-कभी खराब त्रुटियों से ग्रस्त होंगी - और इस प्रकार उपयोग की कमी - try बहुत बार आईएनजी। वे परियोजनाएं मर जाएंगी या तय हो जाएंगी या फोर्क हो जाएंगी।

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

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

मुझे यह पसंद नहीं है कि कैसे कोशिश करें (..) टाइप करते समय सोचने के लिए कोडर के दिमाग के ढेर पर सिर्फ एक और जोड़ी कोष्ठक/कोष्ठक डाल रहा है। और सबसे लंबे समय तक मैं कल्पना कर सकता हूँ!

तो यह बेहतर है:
मान, त्रुटि: = फू ()
अगर गलती हुई है तो वापस लौटें! = शून्य

लेकिन फिर भी यह इतना आम है। तो मैं चाहूंगा कि अगर श्रीमती इस तरह किसी तरह संभव हो सकती हैं:

मान, त्रुटि की जाँच करें: = foo ()

यदि गो एक पठनीय भाषा बनना चाहता है, तो सोचने या समझने में मुश्किल सोचने की क्षमता को कम से कम किया जाना चाहिए।

यदि गो अच्छी त्रुटि प्रबंधन चाहता है, तो उसे त्रुटियों को अतिरिक्त संदर्भ रखने के लिए प्रोत्साहित करना चाहिए क्योंकि वे कॉल स्टैक पर चढ़ते हैं। त्रुटियों को संभालने के लिए defer का उपयोग करने की आवश्यकता भ्रमित करने वाली लगती है। क्या होगा यदि आपके त्रुटि हैंडलर में कोई त्रुटि है? डिफर्स को स्टैक ऑर्डर में निष्पादित किया जाता है, क्या हमें हैंडलर को रिवर्स में घोषित करने की आवश्यकता है?

अगर बयान सीधे हैं, और यहां अस्पष्टता के लिए बहुत कम जगह छोड़ दें। मुझे लगता है कि try वास्तविक इंजीनियरिंग समस्या के बजाय एक नाइट को हल कर रहा है। मुझे यह प्रस्ताव पसंद है क्योंकि यह मूक बहुमत को इन जटिल प्रस्तावों के हर पहलू को पूरी तरह से समझे बिना अंततः एक बयान देने की अनुमति देता है।

@icholi कृपया विनम्र रहें। कृपया गोफर आचार संहिता से अवगत रहें: https://golang.org/conduct। धन्यवाद।

हर कोई: ऊपर मेरी टिप्पणी के अलावा (https://github.com/golang/go/issues/32825#issuecomment-506740412) कृपया https://golang.org/wiki/NoPlusOne से अवगत रहें। "मैं सहमत हूं" या "मैं असहमत हूं" से थोड़ा अधिक कहने वाली टिप्पणी करना उपयोगी नहीं है। इसके बजाय इमोजी बटन का प्रयोग करें। धन्यवाद।

@sanbornm

(मैं मानता हूं कि एक संदेश का उत्तर देना संभव है; मैंने कहा कि यह अजीब था, असंभव नहीं। और थ्रेडिंग के बारे में मेरी बात अभी भी कायम है, जिसमें यह मिनी-थ्रेड अन्य टिप्पणियों के बर्फ़ीले तूफ़ान में खो गया है।)

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

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

(मैं समझता हूं कि इस मामले में प्रस्ताव बी लॉक है; तथ्य यह है कि इस प्रस्ताव में एक दिन से कम समय में 77 टिप्पणियां हैं, यह दिखाता है कि क्यों। इस स्तर की चर्चा केवल समस्या ट्रैकर की बजाय मेलिंग सूची पर बेहतर काम करती है।)

@ianlancetaylor

(मैं मानता हूं कि एक संदेश का उत्तर देना संभव है; मैंने कहा कि यह अजीब था, असंभव नहीं। और थ्रेडिंग के बारे में मेरी बात अभी भी कायम है, जिसमें यह मिनी-थ्रेड अन्य टिप्पणियों के बर्फ़ीले तूफ़ान में खो गया है।)

काफी उचित, यह समझ में आता है। मेलिंग सूचियां बहुत अच्छी हैं लेकिन मुझे व्यक्तिगत रूप से इस मामले में गिटहब के माध्यम से योगदान करना आसान लगता है। वर्तमान त्रुटि प्रबंधन के अलावा मेरे पास कहने के लिए बहुत कुछ नहीं है और मैं चाहता हूं कि यह वही बना रहे। इसके लिए इमोजी/वोट बहुत अच्छे हैं। आप शायद नहीं चाहते कि 100 लोग मेलिंग सूची में "कृपया त्रुटि प्रबंधन को अकेला छोड़ दें" लिखें जहां 100 "वोट" पर्याप्त हों।

चूंकि यह समस्या लॉक है, इसलिए इसे इमोजी के साथ "वोट" नहीं किया जा सकता है। यही कारण है कि मेरा मानना ​​है कि यह मुद्दा पहली जगह में बनाया गया था।

एक पक्ष बिंदु लेकिन संबंधित, निर्भरता प्रबंधन को अच्छी तरह से संभाला नहीं गया था। डेप ने बहुत अच्छा काम किया और गो मॉड को चुना गया (जैसा लग रहा था) कहीं से भी [1]। मैं इसे समझता हूं इसलिए प्रस्ताव प्रणाली बनाई गई थी। मुझे ऐसा लगता है कि इस मामले में प्रस्ताव प्रणाली समुदाय का प्रतिनिधित्व कम कर सकती है यदि मुद्दों को बंद कर दिया जाता है और हमें मेलिंग सूचियों पर जाने के लिए कहा जाता है।

[1] https://twitter.com/_rsc/status/1022588240501661696

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

@sanbornm

डिप ने बहुत अच्छा काम किया

यहां असहमत होने की जरूरत है। गो मॉड्यूल ने अंततः https://proxy.golang.org द्वारा अपने लगातार कैशिंग के साथ उस कुख्यात "gobindata" समस्या को हल किया

उस डिप्टी ड्यूड को समस्या का एहसास भी नहीं था और इसके बजाय वीसीएस के माध्यम से फैंसी "सुनिश्चित" कर रहा था।

@sirkon यह थोड़ा हटकर विषय है, लेकिन आपको इसकी कोई आवश्यकता नहीं है यदि आप वेंडर डिप्स जैसे डेप कर रहे थे।

जैसा कि यह खड़ा है, मुझे लगता है कि मैं चीजों को छोड़ दूंगा क्योंकि वे तब तक हैं जब तक कि अधिक बाधाएं नहीं जोड़ी जातीं, जैसे प्रति पंक्ति 1 प्रयास कथन। प्रस्ताव से इस उदाहरण पर विचार करने का कारण है - यह काफी हानिरहित लगता है info := try(try(os.Open(file)).Stat()) लेकिन यह सामान्य नियंत्रण प्रवाह के दायरे से परे फ़ाइल हैंडल को लीक करता है। मुझे लगता है कि हम io.Closer कार्यान्वयन या अन्य क्लीनअप फ़ंक्शन के साथ फ़ाइल संसाधन लीक में वृद्धि देखेंगे जिससे लोग अधिक कॉम्पैक्ट कोड की खोज में बच सकते हैं।

हो सकता है कि कुछ लोग इसे अप्रासंगिक मानेंगे क्योंकि f अब जीवित नहीं रहेगा और इस प्रकार GC के लिए तुरंत पात्र होगा और किसी बिंदु पर अंतिम रूप यह सुनिश्चित करेगा कि f बंद है। मुझे लगता है कि यह आज defer का उपयोग करने के पिछले स्पष्ट (लिंटर समर्थित) सम्मेलनों को बदलता है जो फ़ंक्शन ब्लॉक से बंधे होते हैं। जब फ़ंक्शन ब्लॉक से बाहर निकल जाता है तो संसाधन मुक्त हो जाता है। कचरा संग्रहकर्ता पर भरोसा करने से कोई गारंटी नहीं मिलती है कि आप संसाधनों को समाप्त नहीं करेंगे (सामान्य खुली फ़ाइल हैंडल सीमा डिफ़ॉल्ट 1k और 4k के बीच हो सकती है) - जिसे आसानी से एक साधारण फ़ाइलपथ से पार कर लिया जाता है। चलना जो फाइलों को बंद नहीं करता है यह आंकड़े।

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

var n int
for _, name in try(os.Readdir(...)) {
   n += try(getSize(name))
}
func getSize(name string) (int, error) {
   return try(try(os.Open(name)).Stat()).Size
}

संपादित करें:
बाधाओं के लिए, मुझे वास्तव में लगता है कि यह केवल असाइनमेंट के दाहिने हाथ पर मान्य था जो प्रति पंक्ति 1 कहने से बेहतर होगा, क्योंकि a, b := try(get("a")), try(get("b")) पर्याप्त उचित है। लेकिन यह अभी भी try(os.Open(name)).Stat() करने की क्षमता छोड़ देता है - जो कि यदि आप try() शून्य बनाना चाहते हैं, लेकिन केवल तभी जब किसी असाइनमेंट के RHS पर नहीं होता है तो आप कुछ ऐसा छोड़ देते हैं जो बहुत काम नहीं करता है सब।

@cstockton वाह महान खोज!

जंग वास्तव में समान मैक्रो ( ? अगर मुझे सही याद है) जो वास्तव में यह try मतलब है, लेकिन उनके पास उचित raii है, इसलिए यह उस भाषा में कोई समस्या नहीं है और एक विशाल हमारे मामले में छेद

@sanbornm हाँ, आधे इंटरनेट को अपने रेपो में रखना वास्तव में एक महान विचार की तरह दिखता है।

चूंकि किसी ने उपयोगिता का उल्लेख किया

| परियोजना | एलओसी* | उम्मीदवारों का प्रयास करें |
|----------|----------|----------------|
| cal1 | 2047 | 3 |
| पंप1 | 1030 | 0 |
| डॉक्स1 | 4576 | 8 |
| हगौटिल | 604 | 1 |
| बाकी सब | 8452 | 23 |

• cloc उपयोगिता के अनुसार, टिप्पणियों को छोड़कर केवल गो कोड।

ध्यान रखें कि "बाकी सब कुछ" की सामग्री में त्वरित हैक्स और कोड शामिल हैं जो मैंने तब लिखा था जब मैं गो सीख रहा था।

मेरा समग्र निष्कर्ष यह है कि मेरे लिए कम से कम, try प्रस्ताव मेरी त्रुटि प्रबंधन को किसी भी सार्थक डिग्री तक सुव्यवस्थित करने में मदद नहीं करेगा।

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

@miekg कृपया इस लिंक को https://github.com/golang/go/issues/32825#issuecomment -506882164 प्रस्ताव में जोड़ें। उदाहरण इस हाल के try कीवर्ड के संपूर्ण विचार को पूरी तरह से अयोग्य घोषित करता है।

मैं इसे ऐसे ही छोड़ने से पूरी तरह सहमत हूं। यह थोड़ा बहुत वर्बोज़ है लेकिन इसका अनुसरण करना बहुत सीधा है।

अगर मैं बस कम कर सकता

if err := foo.x(a, b); err != nil {
  return err
}

if err := foo.y(); err != nil {
  return err
}

if err := foo.z(c); err != nil {
  return err
}

कुछ ऐसा करने के लिए

if err := check foo.x(a, b), foo.y(), foo.z(c); err != nil {
  return err
}

शायद मुहावरे को बहुत ज्यादा IMHO बदले बिना भी अच्छा होगा।

यदि आप "शायद" प्रकार के बारे में बात कर रहे थे, तो इसके लिए पहले भिन्न प्रकार की आवश्यकता होती है।

चलो if err != nil यह काम करता है, यह स्पष्ट है, यह वास्तव में वर्बोज़ नहीं है, और यह कोड के प्रवाह में समझ में आता है। जैसा कि आप इस निर्माण के साथ कोड पढ़ते हैं, आप जानते हैं कि यह क्या करने जा रहा है।
आइए इसे रखें, आइए try न जोड़ें

जब मैं कोड पढ़ता हूं, तो मैं चाहता हूं कि काम करने वाली रेखाएं कम से कम त्रुटि प्रबंधन सामग्री के बिना या बिना स्पष्ट रूप से पठनीय हों।

समान स्तर पर 3 अक्षर 'गलती' मुझे स्वीकार्य हैं। मैं महत्वपूर्ण कोड को लपेटने वाले कुछ 'चेक' फ़ंक्शन को पसंद नहीं करूंगा, क्योंकि महत्वपूर्ण कोड दूसरे स्तर पर होगा (लिस्प याद रखें?), और मैं पहले एक पंक्ति 'कोशिश' नहीं करना चाहूंगा, क्योंकि महत्वपूर्ण कोड इंडेंटेड आएगा और दूसरी पंक्ति पर।

रेस, एरर: = start_job ()
अगर गलती!= शून्य {
हैंडल_एरर ()
}

त्रुटि = जारी रखें_जॉब (रेस)
अगर गलती!= शून्य {
हैंडल_एरर ()
}

इस कोड के साथ, आप ब्लॉक की पहली पंक्तियों को पढ़कर गैर-त्रुटि मामले के प्रवाह को पढ़ सकते हैं (जब मुझे इसे जल्दी से पढ़ना होता है तो मैं डॉक्स के शीर्षक पढ़ता हूं)

चूंकि किसी ने उपयोगिता का उल्लेख किया

प्रोजेक्ट एलओसी* उम्मीदवारों को आजमाएं
कैल 1 2047 3
पंप1 1030 0
डॉक्स1 4576 8
हगौटिल 604 1
बाकी सब 8452 23

• cloc उपयोगिता के अनुसार, टिप्पणियों को छोड़कर केवल गो कोड।

मुझे लगता है कि बड़े कार्यक्रमों में try की अधिक आवश्यकता है। बस स्मृति से ड्राइंग मुझे लगता है कि लगभग 15-20k और ऊपर के LOC आकार वाले कार्यक्रमों को उनकी अधिक आवश्यकता होती है क्योंकि ऐसा तब होता है जब आप परतें प्राप्त करना शुरू कर सकते हैं जिन्हें केवल त्रुटियों को पारित करने की आवश्यकता होती है क्योंकि वे उपयुक्त रूप से निर्दिष्ट होते हैं और एक बंद प्रणाली में नियंत्रित होते हैं। भेजने और प्राप्त करने वाले पक्ष दोनों। यह बहुत कुछ इस बात पर निर्भर करता है कि यह किस प्रकार का कार्यक्रम है। मैं शायद छोटे कार्यक्रमों में भी ज्यादा प्रयोग नहीं करूंगा

मुझे लगता है कि बड़े कार्यक्रमों में प्रयास की अधिक आवश्यकता होती है।

अच्छी बात। मैंने हेप्टियो/समोच्च पर ट्राइहार्ड की कोशिश की, स्रोत टेक्स्ट की 28.7k लाइनें, ट्राइहार्ड को 12 प्रतिस्थापन मिले।

मुझे लगता है कि बड़े कार्यक्रमों में प्रयास की अधिक आवश्यकता होती है।

अच्छी बात। मैंने हेप्टियो/समोच्च पर ट्राइहार्ड की कोशिश की, स्रोत टेक्स्ट की 28.7k लाइनें, ट्राइहार्ड को 12 प्रतिस्थापन मिले।

वाह! 12 बनाम 28.7K लाइनें, इसके लिए वास्तव में समर्पित कीवर्ड की आवश्यकता है!

खैर, मुझे इस पर आपके पीओवी में अधिक दिलचस्पी है:

stat := try(try(os.Open(fileName)).Stat())

मुझे लगता है कि यह अधिक सामान्य है यदि आपका कार्यक्रम थोड़ा अधिक अखंड है और कई सेवाओं के बीच सेवा एकीकरण का हिस्सा नहीं है। जब मैं उस रिपॉजिटरी ( heptio/contour ) पर जीथब में fmt.errorf या errors करता हूं तो केवल बहुत कम परिणाम होते हैं इसलिए त्वरित अवलोकन प्राप्त करना कठिन होता है .. लेकिन जैसा कि मैंने ने कहा कि यह शायद एक कार्यक्रम से दूसरे कार्यक्रम में बहुत भिन्न होता है, यहां तक ​​कि बड़े कार्यक्रमों के लिए भी।

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

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

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

आपको अंदाजा नहीं है। एनोटेशन आसानी से एक तरह से त्रुटि हुई खोजने के लिए हैं। हमारे पास इसी तरह os.NotExist लेकिन यह त्रुटि पथ पर मुश्किल से एक अच्छा संकेत है।

@thomasf यहाँ एक और डेटा बिंदु है, जूजू/जूजू की कई साल पुरानी कामकाजी प्रति से,

529628 स्रोत लाइनों, ट्राइहार्ड ने 1763 (0.3%) प्रतिस्थापन पाया।

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

529628 स्रोत लाइनों, ट्राइहार्ड ने 1763 (0.3%) प्रतिस्थापन पाया।

जैसा कि किसी ने (उद्धरण वांछित) बुद्धिमानी से कहा, try त्रुटियों को संभालना आसान नहीं बनाता है। इससे उन्हें न संभालना आसान हो जाता है।

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

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

ए। ऐसे बहुत से स्थान हैं जहां try मौजूदा गो कोडबेस पर लागू होता है
बी। सामान्य रूप से त्रुटि प्रबंधन SLOC का एक महत्वपूर्ण हिस्सा है, जो मेरे अपने माप और गो टीम द्वारा दिए गए नंबरों के आधार पर है, रेफरी https://youtu.be/RIvL2ONhFBI?t=440 टाइमकोड 07:26

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

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

शायद try आवश्यकता नहीं है क्योंकि कई जगहों पर इसकी आवश्यकता नहीं होगी, लेकिन आइए इस विचार का मनोरंजन करें और इसके बारे में केवल क्रोधी होने के बजाय उपयोग के मामलों के साथ आएं ...

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

var v1, v3 string
if err := func() error {
    try(onething())
    v = try(twothing())
    try(otherthing())
    v3 = try(somethingg())
}(); err != nil {
  ... handle error...
}

मुझे लगता है कि इस समय विभिन्न पैकेजों पर tryhard लिए डेटा रखने और उनकी कल्पना करने के लिए एक वेबसाइट लिखना एक अच्छा विचार हो सकता है। शायद थोड़ा गोलांग/gddo संशोधित करें (godoc.org) काम कर सकता है।

मैं if err != nil अकेला छोड़ना पसंद करता हूं। लेकिन अगर हमें त्रुटि प्रबंधन के लिए कुछ जोड़ना है, तो यहां एक नया प्रस्ताव है जो इसके लिए throws कीवर्ड जोड़ें।

32852

यहां पहले से बताए गए कुछ तर्कों को दोहराए बिना, मैं if err != nil को यथावत छोड़ने की भावना को प्रतिध्वनित करता हूं।

मैं जो परिप्रेक्ष्य पेश कर सकता हूं वह यह है: जिस व्यक्ति ने सैकड़ों नए लोगों के पास जाना सिखाया है (दोनों प्रोग्रामिंग और अन्य भाषाओं से जाने के लिए), if err != nil उनके लिए कभी कोई समस्या नहीं रही है। मेरी कार्यशालाओं में अनुभवी प्रोग्रामर पहली बार में इसे असामान्य पाते हैं लेकिन जल्दी से गो में त्रुटि प्रबंधन की स्पष्ट प्रकृति से प्यार करना सीखते हैं।

बड़ी चिंताएँ हैं जिन्हें हम भाषा में संबोधित कर सकते हैं और इस मुद्दे पर समुदाय की स्पष्ट प्रतिक्रिया कहती है कि if err != nil उनमें से एक नहीं है।

गो कई कारणों से एकदम सही है। उनमें से प्रमुख है "अगर गलती! = शून्य"। यह वर्बोज़ लग सकता है लेकिन कोड सीखने वाले लोगों के लिए, यह आपके कोड और सही कोड को डीबग करना आसान बनाता है।

@davecheney

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

ए। ऐसे बहुत से स्थान हैं जहां try मौजूदा गो कोडबेस पर लागू होता है
बी। सामान्य रूप से त्रुटि प्रबंधन SLOC का एक महत्वपूर्ण हिस्सा है, जो मेरे अपने माप और गो टीम द्वारा दिए गए नंबरों के आधार पर है, रेफरी https://youtu.be/RIvL2ONhFBI?t=440 टाइमकोड 07:26

मुझे डर है कि वर्तमान माहौल में हमें जो भी उदाहरण मिलते हैं उन्हें "अच्छी तरह से शायद अच्छा कोड नहीं है" के रूप में खारिज कर दिया जाएगा।

यहाँ एक उदाहरण है:

llorllale:~/go/src/github.com/hyperledger/fabric$ cloc --exclude-dir=vendor .
    2406 text files.
    2256 unique files.                                          
    3130 files ignored.

http://cloc.sourceforge.net v 1.60  T=6.69 s (272.8 files/s, 58350.9 lines/s)
--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
Go                             1751          54365          34149         294005
YAML                             35            547           2171           2060
Bourne Shell                     26            354            325           1312
make                              3            135             96            418
CSS                               1             40             14            140
HTML                              3              7              5             63
Python                            1             50            103             57
Bourne Again Shell                1              1              6             50
Java                              3              7              4             26
XML                               2              1              4              2
--------------------------------------------------------------------------------
SUM:                           1826          55507          36877         298133
--------------------------------------------------------------------------------

llorllale:~/go/src/github.com/hyperledger/fabric$ tryhard -l . | grep -v vendor | less | wc -l
1417

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

if err != nil {
   return errors.Wrap(err) 
} 

...
if err != nil {
   return errgo.Notef(err, "error doing x") 
} 

जिसे ट्राइहार्ड द्वारा रिपोर्ट नहीं किया जाएगा।

मेरी कंपनी में हमारा ऐसा सम्मेलन है। उन्हें नग्न त्रुटि रिटर्न में वापस लाने के लिए एक साधारण खोज-और-प्रतिस्थापन करना मुझे ये परिणाम देता है:

Language                             files          blank        comment           code
---------------------------------------------------------------------------------------
Go                                    2488          40317          15901         297038

ट्राइहार्ड 2736 प्रतिस्थापनों की रिपोर्ट करता है, लेकिन शेष रैपिंग की मैन्युअल समीक्षा करने से ऐसा लगता है कि यह लगभग 1850 तक कम हो गया है, इसलिए मैं 300k लाइनों के हमारे कोडबेस में कुल ~ 4500 try उपयोगों का अनुमान लगाऊंगा।

(व्यक्तिगत रूप से, मैं त्रुटि प्रबंधन की वर्तमान खोजकर्ता के पक्ष में हूं और इससे कोई आपत्ति नहीं है।)

उदाहरण के लिए, यदि आपकी कंपनी की परंपरा है
[कस्टम संदेश के साथ त्रुटियों को लपेटें]
जिसे ट्राइहार्ड द्वारा रिपोर्ट नहीं किया जाएगा।

यही बात है - try प्रस्ताव केवल if err != nil return err नग्न रिटर्न को सरल करता है, यह कस्टम संदेश और संदर्भ के साथ रैपिंग त्रुटियों का समर्थन नहीं करता है।

if err != nil की एकमात्र दोहराव मुझे विश्वास है कि अन्य वापसी मूल्यों के शून्य मूल्यों को भी निर्दिष्ट करने के लिए तय किया जा सकता है। इसे दूर करने के लिए भाषा को अपडेट किया जा सकता है। उदाहरण के लिए:

आज के गो में, अगर मेरे पास इस हस्ताक्षर के साथ कोई फ़ंक्शन है:

func add(x, y string) (int, error)

कहीं समारोह में, मुझे लिखना होगा:

func add(x, y string) (int, error) {
    // ...
    if err != nil {
        return 0, err
    }

पूरे समारोह में लेखक को समान शून्य मान दोहराने के लिए मजबूर करना।

यह बहुत आसान होगा (और त्रुटि वाचालता और पठनीयता के लिए कम लागत के साथ) यदि भाषा गैर-त्रुटि वापसी मानों के लिए शून्य मानों को स्वचालित रूप से भर सकती है:

func add(x, y string) (int, error) {
    // ...
    if err != nil {
        return ..., err
    }
    // ...
}
func main() {
    add("8", "beep") // returns 0, error(`strconv.ParseInt: parsing "beep": invalid syntax`)
}

मैं बहुत सारे कोड के साथ अनुभव से कह सकता हूं जो डीबी प्रश्नों और कॉलों के साथ इंटरैक्ट करता है, कार्यों में शून्य मानों को दोहराना गो-स्टाइल त्रुटि प्रबंधन का एकमात्र नकारात्मक है। अन्यथा मैं इस प्रस्ताव की भावना से सहमत हूं: if err != nil अकेला छोड़ दो!

नोट: हां, नामित रिटर्न वैल्यू इसे पूरा कर सकते हैं (https://play.golang.org/p/MLV8Y52HUBY), लेकिन इस तकनीक का उपयोग करके अपने कोडबेस में कुछ कार्यों को लागू करने के बाद, मुझे याद दिलाया गया कि कितना फुट -गन नामित वापसी मूल्य हैं; मैं हमेशा नामित वापसी मूल्य को छायांकित करता हूं।

उदाहरण के लिए, यदि आपकी कंपनी की परंपरा है
[कस्टम संदेश के साथ त्रुटियों को लपेटें]
जिसे ट्राइहार्ड द्वारा रिपोर्ट नहीं किया जाएगा।

यही बात है - try प्रस्ताव केवल if err != nil return err नग्न रिटर्न को सरल करता है, यह कस्टम संदेश और संदर्भ के साथ रैपिंग त्रुटियों का समर्थन नहीं करता है।

यह सच है, मैं उस प्रकार के बारे में सोच रहा था जिसने एक वर्णनात्मक स्ट्रिंग जोड़ने की अनुमति दी थी। हमारे त्रुटि रिटर्न का विशाल बहुमत (~4000/4500) एक गैर-संदर्भ errgo.Mask(err) , जिसे मैं बिना विवरण try() बराबर मान रहा था, लेकिन वर्तमान में यह कमी होगी कार्यक्षमता के बाद से errgo स्टैक जानकारी जोड़ता है और कोशिश नहीं करता (अभी तक)।

@ianlancetaylor यहाँ एक प्रस्ताव है। @miekg यह प्रस्तावित कर रहा है कि आप हमारी भाषा के नेताओं में से एक के रूप में if err != nil को किसी अन्य निर्माण के साथ बदलने का प्रयास नहीं करते हैं जो मूल गो लेखकों द्वारा तय किए गए त्रुटि प्रबंधन की भावना के विपरीत है। मेरे लिए व्यक्तिगत रूप से, ऐसा लगता है कि आप इसे हमारे अन्य प्रस्तावों की तरह व्यवहार करने के बजाय इसे golang-nuts ले जाकर इसके महत्व पर जोर देने की कोशिश कर रहे हैं। यह आपका इरादा नहीं हो सकता है, लेकिन मुझे लगता है कि यह प्रभाव है।

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

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

मैं पूछता हूं कि गो टीम अन्य असंबंधित भाषा पुनरावृत्तियों को आगे बढ़ाने के लिए जारी रखते हुए इस प्रस्ताव को स्वीकार करती है, जो एक स्पष्ट मूल्य वर्धित हैं।

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

इस विषय पर पहले से ही Google समूह पर भी चर्चा की जा चुकी है।

#32437 का वर्तमान संस्करण असंतोषजनक है। कोशिश () बिल्टिन अप्रशिक्षित आंखों के लिए बहुत सारे निष्पादन पथ छुपाता है। चेक और हैंडल वाला मूल प्रस्ताव बहुत ही समझने योग्य था और चेक कीवर्ड सबसे अलग था।

अब, try() बिलिन एक फ़ंक्शन की तरह दिखता है - यह स्पष्ट नहीं है कि यह नियंत्रण प्रवाह को बदल सकता है। हमें भी घबराहट होती है (), लेकिन यह (मेरा मानना ​​​​है) हमेशा अपनी एक पंक्ति में है, इसका एक प्रमुख नाम है और इसका उपयोग दुर्लभ है। कोशिश () दूसरी ओर, एक जटिल अभिव्यक्ति के अंदर छिपा सकता है।

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

मैं एक प्रस्ताव के सिद्धांत को नापसंद करता हूं जो त्रुटि प्रबंधन को रोक देगा जैसा कि आज है। ऐसा प्रस्ताव इस विषय पर भविष्य के सभी प्रस्तावों पर रोक लगाएगा।

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

त्रुटि प्रबंधन का हमारा तरीका अद्वितीय है

रस्ट में एरर हैंडलिंग वैचारिक रूप से गो में हम जो करते हैं, उसके समान है (त्रुटियाँ मान हैं, स्पष्ट नियंत्रण प्रवाह, सिवाय इसके कि जब हम इसके बजाय योग प्रकार का उपयोग करते हैं तो हम कई रिटर्न वैल्यू का उपयोग करते हैं)। रस्ट में वही समस्या थी जो गो वर्बोज़ एरर हैंडलिंग के साथ थी। इसने रस्ट को कोशिश जोड़ने के लिए प्रेरित किया! मैक्रो, और अंततः ? ऑपरेटर। मैं कहूंगा कि रस्ट समुदाय त्रुटि प्रबंधन के संबंध में गो समुदाय से भी अधिक सख्त है (त्रुटि प्रबंधन RFC और चर्चाएं ज्ञानवर्धक हैं)। उन्होंने खराब त्रुटि प्रबंधन की फिसलन ढलान के बिना त्रुटि प्रबंधन क्रियाशीलता को कम करने का एक तरीका खोज लिया है। मुझे यकीन है कि हम भी कर सकते हैं।

वर्तमान में हम जिस प्रक्षेप पथ पर हैं, वह भाषा, पारिस्थितिकी तंत्र या उसके उपयोगकर्ताओं के लिए अच्छा नहीं है

तुम्हारी किस बारे में बोलने की इच्छा थी? गो में लगातार सुधार हो रहा है। इतनी महान भाषा, टूलिंग और दस्तावेज़ीकरण तक मुफ्त में पहुंचना आश्चर्यजनक है (जैसा कि मुक्त भाषण में)।

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

मैं एक प्रस्ताव के सिद्धांत को नापसंद करता हूं जो त्रुटि प्रबंधन को रोक देगा जैसा कि आज है। ऐसा प्रस्ताव इस विषय पर भविष्य के सभी प्रस्तावों पर रोक लगाएगा।

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

त्रुटि प्रबंधन का हमारा तरीका अद्वितीय है

रस्ट में एरर हैंडलिंग वैचारिक रूप से गो में हम जो करते हैं, उसके समान है (त्रुटियाँ मान हैं, स्पष्ट नियंत्रण प्रवाह, सिवाय इसके कि जब हम इसके बजाय योग प्रकार का उपयोग करते हैं तो हम कई रिटर्न वैल्यू का उपयोग करते हैं)। रस्ट में वही समस्या थी जो गो वर्बोज़ एरर हैंडलिंग के साथ थी। इसने रस्ट को कोशिश जोड़ने के लिए प्रेरित किया! मैक्रो, और अंततः ? ऑपरेटर। मैं कहूंगा कि रस्ट समुदाय त्रुटि प्रबंधन के संबंध में गो समुदाय से भी अधिक सख्त है (त्रुटि प्रबंधन RFC और चर्चाएं ज्ञानवर्धक हैं)। उन्होंने खराब त्रुटि प्रबंधन की फिसलन ढलान के बिना त्रुटि प्रबंधन क्रियाशीलता को कम करने का एक तरीका खोज लिया है। मुझे यकीन है कि हम भी कर सकते हैं।

वर्तमान में हम जिस प्रक्षेप पथ पर हैं, वह भाषा, पारिस्थितिकी तंत्र या उसके उपयोगकर्ताओं के लिए अच्छा नहीं है

तुम्हारी किस बारे में बोलने की इच्छा थी? गो में लगातार सुधार हो रहा है। इतनी महान भाषा, टूलिंग और दस्तावेज़ीकरण तक मुफ्त में पहुंचना आश्चर्यजनक है (जैसा कि मुक्त भाषण में)।

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

@ianlancetaylor यहाँ एक प्रस्ताव है। @miekg यह प्रस्तावित कर रहा है कि आप हमारी भाषा के नेताओं में से एक के रूप में if err != nil को किसी अन्य निर्माण के साथ बदलने का प्रयास नहीं करते हैं जो मूल गो लेखकों द्वारा तय किए गए त्रुटि प्रबंधन की भावना के विपरीत है। मेरे लिए व्यक्तिगत रूप से, ऐसा लगता है कि आप इसे हमारे अन्य प्रस्तावों की तरह व्यवहार करने के बजाय इसे golang-nuts ले जाकर इसके महत्व पर जोर देने की कोशिश कर रहे हैं। यह आपका इरादा नहीं हो सकता है, लेकिन मुझे लगता है कि यह प्रभाव है।

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

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

मैं पूछता हूं कि गो टीम अन्य असंबंधित भाषा पुनरावृत्तियों को आगे बढ़ाने के लिए जारी रखते हुए इस प्रस्ताव को स्वीकार करती है, जो एक स्पष्ट मूल्य वर्धित हैं।

वे 60 के दशक से वर्तमान प्रकार की प्रणाली के साथ कुछ भी गंभीर नहीं कर सकते। उन्हें अंततः अपने गो 2.0 . में 80 के दशक के विचारों को उधार लेने की आवश्यकता है

तुम्हारी किस बारे में बोलने की इच्छा थी? गो में लगातार सुधार हो रहा है। इतनी महान भाषा, टूलिंग और दस्तावेज़ीकरण तक मुफ्त में पहुंचना आश्चर्यजनक है (जैसा कि मुक्त भाषण में)।

@ngrilly कि अंतिम भाग शायद एक बड़ी चर्चा के लिए है। इस प्रस्ताव को पटरी से उतारे बिना, लेकिन उस टिप्पणी को कुछ हद तक बंद करके, समुदाय/पारिस्थितिकी तंत्र में उपयोगकर्ताओं और नेतृत्व के बीच गलत संरेखण की भावना बढ़ रही है।

बाकी चर्चा के लिए, मुझे नहीं लगता कि वाक्य रचना में अधिक संज्ञानात्मक उपरि जोड़ना एक जीत है। मुझे खुशी है कि उन्हें कुछ ऐसा मिला जिसने उनके लिए काम किया, हम वे नहीं हैं।

मैंने इनलाइन इफ स्टेटमेंट के लिए अभी एक प्रस्ताव खोला है: https://github.com/golang/go/issues/32860

संदर्भ: https://github.com/golang/go/issues/32825#issuecomment -506707539

यह दुनिया कितनी अच्छी हो जाएगी यदि हर कोई अपना प्रस्ताव प्रस्तुत करता है कि जो भी नया गोलंग 2.0 फीचर वे बस इतना पसंद करेंगे, वह https://github.com/golang/go के अपने कांटे की एक शाखा भी प्रदान करेगा (और जो कुछ भी अन्य आवश्यक भंडार) जो उस प्रस्ताव को लागू करता है।

क्या आप सहमत नहीं हैं?

@ av86743 इस प्रस्ताव के दायरे से बाहर लगता है। कृपया उस कार्रवाई का सुझाव देते हुए एक प्रस्ताव दाखिल करें।

मुझे इसके साथ कुछ चुनौती दिखाई देती है, जैसे कि प्रस्ताव दस्तावेज़ में किसी चीज़ के आधार पर किसी के द्वारा इसे ठुकराने से पहले बहुत सारे व्यर्थ प्रयास का जोखिम। फिर आपने वह सारा समय एक कांटे पर बिताया जिसकी समीक्षा भी नहीं की जाएगी।

इस वाक्यविन्यास के बारे में कैसे:

# call error handler
try callFunction(), errorHandler()

# error handler with anonymous function
variable := try callSomething(), func(err *Error) { # error handling }

@theckman मैं माफी माँगता हूँ अगर ऐसा लगता है कि इस चर्चा को कहीं और ले जाने के मेरे सुझाव से ऐसा लगता है कि यह महत्वहीन है। मैंने अपने अनुरोध में अपने कारण बताए, और मुझे विश्वास है कि वे अभी भी कायम हैं। गो टीम मेलिंग सूची चर्चाओं के साथ-साथ प्रस्तावों पर भी विचार करती है।

चूंकि आप "मूल गो लेखक" का उल्लेख करते हैं, मुझे लगता है कि यह इंगित करने योग्य है कि "कोशिश" प्रस्ताव @griesemer द्वारा बनाया गया था जो तीन मूल गो लेखकों में से एक है।

मैं इस प्रस्ताव से दृढ़ता से सहमत हूं, मुझे लगता है कि केवल एक चीज को बदलने की जरूरत है बस जाओ fmt, एक लाइन इफ स्टेटमेंट की अनुमति देने के लिए fmt करें।

मुझे वास्तव में की एक पंक्ति चाहिए

if err != nil { return wrappedErr{err} }

की तीन पंक्तियों के बजाय

if err != nil {
    return wrappedErr{err}
}

@ av86743 इस प्रस्ताव के दायरे से बाहर लगता है। कृपया उस कार्रवाई का सुझाव देते हुए एक प्रस्ताव दाखिल करें।

@theckman आप मुझे बता रहे हैं कि क्या करना है, और यह सिर्फ विनम्र नहीं है, यह बाहरी रूप से कठोर है। आप अपने आप को किसी भी तरह से चुनने का प्रयास कर सकते हैं, हालांकि न तो मैं और न ही, संभवतः, यहां कोई और आपका "गो फ़ेच" बंदर है जब आप ऐसा कहते हैं।

मुझे इसके साथ कुछ चुनौती दिखाई देती है, जैसे कि प्रस्ताव दस्तावेज़ में किसी चीज़ के आधार पर किसी के द्वारा इसे ठुकराने से पहले बहुत सारे व्यर्थ प्रयास का जोखिम। फिर आपने वह सारा समय एक कांटे पर बिताया जिसकी समीक्षा भी नहीं की जाएगी।

यह केवल [... _विवरण संक्षिप्तता_ के लिए छोड़ी गई पूरी तरह से उपयुक्त भाषा में एक "व्यर्थ प्रयास" होगा।

एक कोडर के लिए, हालांकि, यह एक मामूली, लेकिन उपयोगी अभ्यास होगा और साथ ही, गो समुदाय के लिए एक सेवा होगी।

@ av86743 मुझे लगता है कि आपने जो सुझाव दिया है वह एक दिलचस्प विचार है और मैं नहीं चाहता था कि यह एक असंबंधित मुद्दे में एक टिप्पणी के रूप में खो जाए। यदि विचार के लिए आधिकारिक क्षमता में इसे आगे बढ़ाने में आपकी कोई दिलचस्पी नहीं है, तो मैं इस बात की वकालत करने के लिए क्षमा चाहता हूं कि आप एक अलग मुद्दा उठाते हैं।

भले ही यह विशिष्ट प्रस्ताव @griesemer से आता है, मुझे यह विश्वास करना कठिन लगता है कि वह

इसके लायक क्या है, मेरा निजी संदेह यह है कि इस पर गो टीम की तर्क प्रक्रिया कुछ इस प्रकार है:

1. गो बेहद लोकप्रिय और व्यापक रूप से उपयोग किया जाता है, इसलिए हजारों लोगों के पास स्वाभाविक रूप से इसके बारे में टिप्पणियां, सुझाव और शिकायतें हैं।
2. आप केवल इतने लंबे समय तक पत्थरबाजी कर सकते हैं। गो टीम समुदाय के सभी शोर-शराबे के बारे में कुछ करने के लिए भारी दबाव में महसूस करती है।
3. यह हुई न बात।

कैसे पकड़ने के लिए एक पकड़ () फ़ंक्शन जोड़ने के बारे में अगर कोशिश को कुछ त्रुटि मिली जैसे पुनर्प्राप्ति ()।
उदाहरण:

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

कई कार्यों पर

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
    file1 := open("file1")
    defer file1.Close()
    file2 := open("file2")
    defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

कैसे पकड़ने के लिए एक पकड़ () फ़ंक्शन जोड़ने के बारे में अगर कोशिश को कुछ त्रुटि मिली जैसे पुनर्प्राप्ति ()।
उदाहरण:

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

कई कार्यों पर

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
  file1 := open("file1")
  defer file1.Close()
  file2 := open("file2")
  defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

यह प्रत्येक त्रुटि को अलग तरीके से संभालने में कैसे मदद करता है?

कुछ स्पष्टीकरण:

1. try प्रस्ताव न तो नए सिंटैक्स का परिचय देता है और न ही एक नया कीवर्ड, जो कुछ लोग इस थ्रेड पर दावा कर रहे हैं। यह केवल एक नए बिल्ट-इन का परिचय देता है, सबसे न्यूनतम परिवर्तन के बारे में जो नई कार्यक्षमता जोड़ने में सक्षम हो सकता है। कृपया इस पर चर्चा करते समय सटीक रहें, क्योंकि यह मायने रखता है। नया सिंटैक्स और नया कीवर्ड जोड़ने और बिल्ट-इन के बीच बहुत बड़ा अंतर है। पहला एक बड़ा बदलाव है, बाद वाला एक अपेक्षाकृत मामूली बदलाव है। try प्रस्ताव जो सुझाव देता है वह अपेक्षाकृत मामूली जोड़ है।

2. मैं @ianlancetaylor से सहमत

3. दरअसल, @bitfield , मेरे पास शून्य " गो में अलिखित त्रुटि रिटर्न की क्रिया के बारे में आंतरिक क्रोध" है , धन्यवाद :-) लेकिन मुझे लगता है कि त्रुटि जांच अधिक क्रियात्मक है जो शायद आवश्यक है; और यह तथ्य कि समुदाय द्वारा बार-बार इसी भावना को सामने लाया गया है, एक स्पष्ट संकेतक है कि हम (गो टीम) इस विश्वास के साथ अकेले नहीं हैं। मैं यह नहीं कहूंगा कि "कुछ" करने के लिए बहुत दबाव है - हम इस पर लंबे समय से काम कर रहे हैं, और हम "सही" दृष्टिकोण की प्रतीक्षा करने के लिए काफी संतुष्ट हैं .

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

@griesemer कोशिश बहुत त्रुटि प्रवण है: गो में कोई

@ सिरकॉन , मुझे यकीन नहीं है कि try if ..., err := f(); err != nil { return ..., err } मौजूदा पैटर्न को ... := try(f()) । यदि try का उपयोग करके कोई संसाधन मुक्त बग था, तो यह निश्चित रूप से पहले से भी अस्तित्व में था। try की शुरूआत न तो संसाधन मुक्त बग को बढ़ाती है और न ही रोकती है।

@ सिरकॉन , मुझे यकीन नहीं है कि try if ..., err := f(); err != nil { return ..., err } मौजूदा पैटर्न को ... := try(f()) । यदि try का उपयोग करके कोई संसाधन मुक्त बग था, तो यह निश्चित रूप से पहले से भी अस्तित्व में था। try की शुरूआत न तो संसाधन मुक्त बग को बढ़ाती है और न ही रोकती है।

धागा पढ़ें, एक उदाहरण था:

info := try(try(os.Open(fileName)).Stat())

@ सिर्कोन मैंने उस उदाहरण को कई बार देखा है। मैं सहमत हूं कि यह दिलचस्प है। लेकिन आइए इसके बारे में थोड़ा और सोचें। प्रस्तावित try बिल्टिन मूल रूप से गो कोड में पाए जाने वाले एक निश्चित प्रकार के बॉयलरप्लेट के लिए वाक्यात्मक चीनी है। तो हम उस उदाहरण को मूल कोड में बदल सकते हैं।

    f, err := os.Open(fileName)
    if err != nil {
        return err
    }
    info, err := f.Stat()
    if err != nil {
        return err
    }

उस कोड में एक ही बग है। मैंने निश्चित रूप से ऐसा कोड देखा है। यह मेरे लिए स्पष्ट नहीं है कि try बिल्टिन उस बग को लिखना आसान या देखने में कठिन बनाता है।

[ऐसा लगता है कि @ianlancetaylor ने मुझे बस हरा दिया।]

@sirkon यह बग पहले से ही संभव है, try या नहीं - गो आपको खराब कोड लिखने से नहीं रोकता है। या इसे बदलना, खराब कोड का उपयोग एक कारण के रूप में क्यों try अनुमति नहीं दी जानी चाहिए, यह एक ठोस तर्क नहीं है। इसके बजाय, go vet को समस्याग्रस्त मामलों को फ़्लैग करना चाहिए।

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

f := try(os.Open(filename))
defer f.Close()
info := try(f.Stat())

इसकी तुलना करें:

f, err := os.Open(filename)
if err != nil {
   return ..., err
}
defer f.Close()
info, err := f.Stat()
if err != nil {
   return ..., err
}

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

defer errd.Wrap(&err, "failed to do X for %s", filename)
f := try(os.Open(filename))
defer f.Close()
info := try(f.Stat())

errd पैकेज जैसी किसी चीज़ का उपयोग करना (समस्या #32676 देखें)।

@griesemer
मेरी भविष्य की स्वयं की कोड समीक्षा अभी भी चिल्लाती रहती है कि नियंत्रण प्रवाह तंत्र अपनी लाइन पर होना चाहिए। क्या यह दृष्टिकोण वर्तमान प्रस्ताव के भीतर वैध (कोई प्रवर्तन नहीं) हो सकता है? पठनीयता के अलावा, अधिक विस्तृत त्रुटि प्रबंधन तर्क के लिए रिफैक्टरिंग को आसान बनाया गया है।

defer errd.Wrap(&err, "failed to do X for %s", filename)
f, err:= os.Open(filename)
try(err) // check is so much a better term
defer f.Close()
info, err := f.Stat()
try(err)

साथ ही, handle लिए यह दृष्टिकोण यहां बहुत अच्छा लग रहा है, लेकिन क्या एकाधिक विलंब गड़बड़ नहीं करेंगे? या कोई फ़ंक्शन-स्कोप्ड सिंक होगा। एक बार की तरह की बात (मुझे गलत मुद्दे में स्पष्टीकरण नहीं दिखाई दिया)? यदि हां, तो क्या अनाम कार्यों को अपना दायरा दिया जाएगा? और शैडोइंग... ईश - कौन पहले पर है, दूसरे पर क्या है?

यह सब ऐसा लगता है कि गो कोड लिखने के दो "मोड" होंगे। कहो ऐसा नहीं है।

@griesemer जब आप सही कह रहे हैं तो आज भी बग संभव है, मुझे दृढ़ता से लगता है कि यह भविष्य में try के वर्तमान कार्यान्वयन के साथ अधिक प्रचलित हो जाएगा। कोई भी लगभग _any_ लोकप्रिय भाषा से आ रहा है जो मैं कर सकता हूं ()। सोच। (है) चेनिंग ()। (तरीके) बेहतर या बुरे के लिए उनमें शामिल हैं। ये सभी भाषाएं अपने-अपने मुहावरे प्रदान करती हैं जो पैटर्न को प्राकृतिक और सुरक्षित बनाती हैं। उन्होंने गो के साथ एक तत्काल रोड ब्लॉक मारा क्योंकि टाइप सिस्टम उन्हें प्रत्येक मान को एक साथ विफलता की स्थिति के साथ असाइन करने के लिए मजबूर करता है, इससे बचने के लिए कोई उचित पैटर्न नहीं है (या कोशिश प्रस्ताव मौजूद नहीं होगा)।

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

जो मुझे इस बात पर लाता है कि मैं "आप पहले से ही आज ऐसा कर सकते हैं" कथन से असहमत क्यों हैं - क्योंकि आप बस नहीं कर सकते। ज़रूर - आप एक फ़ाइल हैंडल लीक कर सकते हैं। लेकिन गो प्रोग्रामर को पहचानकर्ता को दायरे में रखने और इस तरह फ़ाइल को लीक करने का अवसर नहीं देता है। प्रत्येक पहचानकर्ता f छोड़ दिया गया एक फ़ाइल हैंडल लीक हो गया है। सुविधा का उपयोग _requires_ कि गो पारिस्थितिकी तंत्र में कुछ प्रमुख मुहावरे टूट गए हैं। इस प्रकार- आज के रूप में डिज़ाइन की गई सुविधा को पेश करने से गो में संसाधनों के लीक होने का खतरा बढ़ जाता है।

जैसा कि मैंने https://github.com/golang/go/issues/32825#issuecomment -506882164 में उल्लेख किया है, मैं वास्तव में try समर्थन करूंगा यदि कुछ छोटे समायोजन किए गए थे, तो मुझे लगता है कि परिवर्तन एक होगा भाषा के अलावा स्वागत किया। मुझे लगता है कि केवल कोशिश की जरूरत है कि इसे केवल एक असाइनमेंट के आरएचएस पर मान्य किया जाए और वापसी मूल्य को पता करने योग्य न होने दिया जाए। कोशिश के उपयोग के "अच्छे" उदाहरण बनाएं (प्रति पंक्ति एक प्रयास करें) प्रयास का उपयोग करने का "केवल" तरीका बनें, यानी:

info := try(try(os.Open(filename)).Stat()) // compiler error
f := try(os.Open(filename)) // valid
// we were forced to assign f, so we still have an identifier to Close (serve linters and users alike)
defer f.Close()
info := try(f.Stat())
a, b := try(strconv.Atoi("1")), try(strconv.Atoi("2")) // also valid 
a, b := try(strconv.Atoi("1"), strconv.Atoi("2")) // maybe?
a, b := try strconv.Atoi("1"), strconv.Atoi("2")

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

total := try(try(os.Open(filename)).Stat()).Size() + try(strconv.Atoi(try(ioutil.ReadAll(os.Stdin))))

लेकिन _हम_ सबसे बुरा सोचेंगे, अगर आप हमें जाने दें।

@daved try(err) को दूसरी पंक्ति पर रखना मौजूदा try प्रस्ताव के साथ पूरी तरह से समर्थित है: try केवल एक तर्क चाहता है जो एक या अधिक मानों का मूल्यांकन करता है जहां अंतिम मान है टाइप करें error , जो स्वाभाविक रूप से संतुष्ट होता है जब आप try(err) लिखते हैं।

मुझे यकीन नहीं है कि मैं defer संबंध में आपकी चिंता का पालन करता हूं - यदि अलग-अलग हैंडलर की आवश्यकता है, तो defer सही विकल्प नहीं हो सकता है; इसके बजाय पारंपरिक if आवश्यकता हो सकती है (जैसा कि प्रस्ताव में बताया गया है)।

@cstockton मैं मानता हूं कि नेस्टेड try बहुत समस्याग्रस्त हो सकता है; लेकिन मैं यह भी मानता हूं कि अगर हमारे पास try , तो अधिकांश कोड आपके द्वारा दिए गए (वैध)

शैली के मामले में, हमने उस भाषा पर प्रतिबंध नहीं लगाया है, जिस पर आप भाषा का समर्थन कर रहे हैं - हमने उसके लिए go vet किया है। अंत में, लिखित सॉफ्टवेयर के लिए प्रभाव समान है। लेकिन भाषा में न होने से हम अपने आप को बांध नहीं रहे हैं। उन प्रतिबंधों को ठीक करना मुश्किल है, और वे कल्पना को अनावश्यक रूप से जटिल बनाते हैं। go vet को समायोजित करना और भाषा को समायोजित करने से अधिक सीखने के साथ-साथ इसे अधिक स्मार्ट बनाना बहुत आसान है।

@griesemer स्पष्टीकरण के लिए धन्यवाद। कोड उदाहरण में, यदि पहली पंक्ति var err error , तो क्या रैप संभावित रूप से दोनों चेक की गई त्रुटियों को प्रभावित करेगा? मैंने देखा है कि शैडोइंग के बारे में बात करना एक चिंता का विषय है जिससे भविष्य में निपटा जा सकता है। यह इससे कैसे संबंधित है/हो सकता है?

कैसे पकड़ने के लिए एक पकड़ () फ़ंक्शन जोड़ने के बारे में अगर कोशिश को कुछ त्रुटि मिली जैसे पुनर्प्राप्ति ()।
उदाहरण:

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

कई कार्यों पर

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
    file1 := open("file1")
    defer file1.Close()
    file2 := open("file2")
    defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

यह प्रत्येक त्रुटि को अलग तरीके से संभालने में कैसे मदद करता है?

अन्य उपयोगकर्ताओं की तरह प्रतिबद्ध

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    file1 :=try open("file1")
    defer file1.Close()
    file2 :=try open("file2")
    defer file2.Close()

        //without try
       file3,err := open("file3")
       defer file3.Close()
 }

@daved इन उदाहरणों में, यह धारणा थी कि err परिणाम का नाम है error । try हमेशा उस परिणाम त्रुटि चर को सेट करेगा, चाहे नाम कोई भी हो (या किसी नाम की अनुपस्थिति)। यदि आपके पास err नामक एक स्थानीय चर है तो वह एक भिन्न चर है। यदि आप परिणाम त्रुटि का उल्लेख करना चाहते हैं, तो इसका एक अलग नाम होना चाहिए। ध्यान दें कि यह पहले से ही मामला है कि यह मान्य नहीं है:

func f(...) (..., err error) {
   var err error // << err already declared
   ...

दूसरी ओर, यदि आप लिखते हैं:

func f(...) (..., err error) {
   a, b, ... err := g() // redeclaration of err
   ...

असाइनमेंट में err बस वही है जो परिणाम पैरामीटर सूची में नामित है। यहां बहुत लंबे समय से जो मामला था, उससे अलग कुछ भी नहीं है।

पुनश्च: हमें शायद इस मुद्दे को try चर्चाओं के लिए अपहरण करना बंद कर देना चाहिए और मूल प्रस्ताव पर वापस जाना चाहिए - इसे अनलॉक किया जाएगा और कल (1 जुलाई) को फिर से चर्चा के लिए खोल दिया जाएगा।

@godcong A catch() फ़ंक्शन (या समान) आपको केवल त्रुटि प्राप्त करने की अनुमति देगा, इसे सेट करने की नहीं (और आमतौर पर कोई त्रुटि हैंडलर के रूप में काम कर रहे एक स्थगित फ़ंक्शन में संलग्न फ़ंक्शन की त्रुटि सेट करना चाहता है) . इसे catch() रिटर्न एक *error बनाकर काम करने के लिए बनाया जा सकता है जो संलग्न फ़ंक्शन के त्रुटि वापसी मान का पता है। लेकिन भाषा में एक नया तंत्र जोड़ने के बजाय त्रुटि परिणाम नाम का उपयोग क्यों न करें? try प्रस्ताव भी देखें जहां इस पर चर्चा की गई है।

इसके अलावा, ऊपर पीएस देखें।

@griesemer

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

मुझे लगता है कि यह वास्तव में try() प्रस्ताव का घातक दोष है: जहां पहले त्रुटि जांच करने का एक और केवल एक ही तरीका था, अब दो होंगे, जो कोड आधार के माध्यम से परस्पर जुड़े हुए हैं। इसके अलावा, कोड आधार के लिए कम से कम मैं पर काम कर रहा हूँ, की तुलना में कम 20% if err != nil साथ बदला जा सकता try() , जबकि एक बनाने के लिए पर्याप्त है जबकि तुच्छ नहीं, मूल्य की तरह प्रतीत नहीं होता त्रुटि प्रबंधन शैलियों में विभाजित।

व्यक्तिगत रूप से मैं एक त्रुटि प्रबंधन निर्माण को प्राथमिकता देता जो सभी if err != nil मामलों में से 95% को बदलने के लिए पर्याप्त शक्तिशाली है। मुझे लगता है कि बहुत से लोगों को भी यही पसंद आया होगा।

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

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

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

@ सिर्कोन मैंने उस उदाहरण को कई बार देखा है। मैं सहमत हूं कि यह दिलचस्प है। लेकिन आइए इसके बारे में थोड़ा और सोचें। प्रस्तावित try बिल्टिन मूल रूप से गो कोड में पाए जाने वाले एक निश्चित प्रकार के बॉयलरप्लेट के लिए वाक्यात्मक चीनी है। तो हम उस उदाहरण को मूल कोड में बदल सकते हैं।

    f, err := os.Open(fileName)
    if err != nil {
        return err
    }
    info, err := f.Stat()
    if err != nil {
        return err
    }

उस कोड में एक ही बग है। मैंने निश्चित रूप से ऐसा कोड देखा है। यह मेरे लिए स्पष्ट नहीं है कि try बिल्टिन उस बग को लिखना आसान या देखने में कठिन बनाता है।

यह मेरे लिए स्पष्ट है कि "धीमा" पारंपरिक प्रवाह नोटिस फ़ाइल को बंद करने के लिए अधिक जगह छोड़ देता है और यह try इस तरह के लीक को उकसाता है क्योंकि लोग लंबे समय से शॉर्टकट पसंद करते हैं।

@godcong A catch() फ़ंक्शन (या समान) आपको केवल त्रुटि प्राप्त करने की अनुमति देगा, इसे सेट करने की नहीं (और आमतौर पर कोई त्रुटि हैंडलर के रूप में काम कर रहे एक स्थगित फ़ंक्शन में संलग्न फ़ंक्शन की त्रुटि सेट करना चाहता है) . इसे catch() रिटर्न एक *error बनाकर काम करने के लिए बनाया जा सकता है जो संलग्न फ़ंक्शन के त्रुटि वापसी मान का पता है। लेकिन भाषा में एक नया तंत्र जोड़ने के बजाय त्रुटि परिणाम नाम का उपयोग क्यों न करें? try प्रस्ताव भी देखें जहां इस पर चर्चा की गई है।

इसके अलावा, ऊपर पीएस देखें।

गो का टाइप सिस्टम 60 के दशक में अटका हुआ था और इस तरह स्वाभाविक रूप से किनारे के मामलों को अच्छी तरह से संभालने में असमर्थ था। यदि आप 80 के दशक के विचारों को उधार लेने के लिए पर्याप्त दूरदर्शी थे तो आपके पास सूक्ष्म त्रुटि-प्रवण प्रवाह को नियंत्रित करने के तरीके होंगे। आप अब मध्ययुगीन गाँव में कांच और धातु की इमारत बनाने की कोशिश कर रहे हैं: बुरी बात यह है कि इन मध्यकालीन गाँवों में बिजली और पानी के पाइप नहीं हैं इसलिए आपके पास भी नहीं होगा।

यह देखना दिलचस्प होगा कि golang/go ही किस हद तक जो भी नई और बेहतर गलत सुविधाएं दी जाएंगी। अगर सब पर।

यह देखना भी दिलचस्प होगा कि क्या go2 fmt सादा go1.x आउटपुट करने का विकल्प होगा।

अपने स्वयं के अनुभव से, जब से मैंने अपनी लौटाई गई त्रुटि में संदर्भ जोड़ा है:

import "github.com/pkg/errors"
func caller(arg string) error {
  val, err := callee(arg)
  if err != nil {
    return errors.Warpf(err, "failed to do something with %s", arg)
  }

  err = anotherCallee(val)
  if err != nil {
    return errors.Warpf(err, "failed to do something with %s", val)
  }

  return nil
}

उत्पादन में उत्पन्न होने वाली समस्याओं के लिए समर्थन टीम को शायद ही कभी मेरे इनपुट की आवश्यकता होती है।

IMHO, मेरा मानना ​​है कि त्रुटि सौंपने में सुधार बॉयलरप्लेट कोड को कम करने के बारे में नहीं है, बल्कि त्रुटियों के संदर्भ को जोड़ने का एक अधिक सुविधाजनक तरीका प्रदान करता है। मुझे अभी भी कोशिश() का उपयोग करने का एक अच्छा समझदार तरीका नहीं मिल रहा है।

शायद संदर्भ को आस्थगित में जोड़ें:

func caller(arg string) (err error) {
  defer func() {
    switch t := err.(type) {
      case CalleeErr:
        err = errors.Wrapf(err, "failed to do something with %s", arg)
      case AnotherCalleeErr:
        err = errors.Wrapf(err, "failed to do something with %s", val)
    }
  }()

  val := try(callee(arg))
  try(anotherCallee(val)
  return nil
}

ऐसा लगता है कि बहुत अधिक टाइपिंग नहीं बचा है, लेकिन हम पठनीयता और प्रदर्शन का त्याग करते हैं।

इस तरह try() का उपयोग करके समाप्त हो सकता है:

func caller(arg string) error {
    val, err := callee(arg)
    try(errors.Warpf(err, "failed to do something with %s", arg))

    err = anotherCallee(val)
    try(errors.Warpf(err, "failed to do something with %s", val))

    return nil
  }

यह कुछ पंक्तियों को कम करता है, बस।

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

हालांकि मुझे यह अच्छा लगेगा अगर हमारे पास if और return एक विशेष मामला हो सकता है जो कि रूबी जैसा दिखता है

return err if err != nil

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

कैसे पकड़ने के लिए एक पकड़ () फ़ंक्शन जोड़ने के बारे में अगर कोशिश को कुछ त्रुटि मिली जैसे पुनर्प्राप्ति ()।
उदाहरण:

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

कई कार्यों पर

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
  file1 := open("file1")
  defer file1.Close()
  file2 := open("file2")
  defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

यह प्रत्येक त्रुटि को अलग तरीके से संभालने में कैसे मदद करता है?

अन्य उपयोगकर्ताओं की तरह प्रतिबद्ध

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

  file1 :=try open("file1")
  defer file1.Close()
  file2 :=try open("file2")
  defer file2.Close()

        //without try
       file3,err := open("file3")
       defer file3.Close()
 }

आपके उदाहरण में आप सभी त्रुटियों को एक ही defer द्वारा संभालते हैं। यदि आप त्रुटि में कस्टम संदेश और कस्टम जानकारी जोड़ना चाहते हैं तो क्या होगा?

@ianlancetaylor क्या किसी ने "अनुमानित रिटर्न" का समर्थन करने के लिए ": =" ऑपरेटर को बढ़ाने का सुझाव दिया है - मूल रूप से फ़ंक्शन कॉल के बिना प्रयास के समान व्यवहार करें। यह बहुत सारी चिंताओं को हल करेगा जो मैंने दोनों पक्षों में देखी हैं:

• try सुविधा के लिए एक नाम के रूप में विवादास्पद रहा है, जब तक हम इसे एक फ़ंक्शन के रूप में लागू करते हैं, हम इसे एक ऐसा नाम देते हुए अटक जाते हैं कि मुझे यकीन नहीं है कि कोई भी इसके बारे में 100% अच्छा महसूस करेगा।
• try एक अभूतपूर्व संख्या में चीजें करता है, इसमें append() जैसे इनपुट होते हैं और एक सर्वव्यापी पैटर्न की जगह लेते हुए panic() जैसे नियंत्रण प्रवाह को प्रभावित करते हैं ( if err != nil ) .
• try नेस्टिंग इसे एक फ़ंक्शन के रूप में लागू करने के निर्णय का परिणाम है, न कि कठोर तकनीकी बहस से प्राप्त मूल्य-वर्धित के रूप में।
• try पश्च संगतता बनाए रखने के लिए एक फ़ंक्शन के रूप में कार्यान्वित किया जाता है

मुझे लगता है कि अगर हम केवल रिटर्न का अनुमान लगाते हैं जैसे हम टाइप करते हैं, तो चीजें संक्षिप्त दिखती हैं और अधिक "गो" महसूस होती हैं जैसे:

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

info, err := f.Stat()
if err != nil {
   return ..., err
}

_इस व्यवहार के लिए यहां सही कंप्यूटर विज्ञान विवरण डालें_, तब तक लघु परिवर्तनीय घोषणाओं के माध्यम से अनुमानित रिटर्न के लिए समझौता करें:

f := os.Open(filename)
defer f.Close()
info := f.Stat()

जो इससे कहीं ज्यादा साफ दिखता है:

f := try(os.Open(filename))
defer f.Close()
info := try(f.Stat())

यह उन सभी चिंताओं को हल करता है जिन्हें मैंने ऊपर सूचीबद्ध किया है (मेरी राय में) थोड़ा और "जैसे जाओ" महसूस कर रहा हूं और पीछे की संगतता बनाए रखता हूं। यह समझाना थोड़ा आसान भी लगता है, try() लिए फ़ंक्शन कॉल पर "अंतर्निहित" रिटर्न वास्तव में हर दूसरी भाषा में try के सर्वव्यापी अर्थ को देखते हुए जगह से बाहर लगता है। मैं कार्यान्वयन के लिए 100% नहीं बोल सकता, लेकिन ऐसा लगता है कि यह लगभग उसी प्रयास से संभावित रूप से किया जा सकता है? AssignStmt में एक फ़ील्ड जोड़ा जा सकता है जो निर्दिष्ट करता है कि एलएचएस पर कौन से अभिव्यक्ति बिल्टिन के समान बैकएंड संकलन को सूचित करने के लिए अपने गलत मूल्यों को छोड़ देती है?

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

इस उदाहरण में, हर बार err सेट होने पर on शर्त का मूल्यांकन किया जाता है।

func example() (foo int, err error) {
    on err != nil {
        return foo, err
    }

    foo, err = calcThis()
    foo, err = calcThat(foo)

    return
}

यह फ़ंक्शन हस्ताक्षर में वापसी मानों के नाम घोषित किए बिना भी काम करता है।

func example() (*int, error) {
    var err error

    on err != nil {
        return nil, err
    }

    foo, err = calcThis()
    foo, err = calcThat(&foo)

    return &foo, nil
}

इसे कई बार सेट भी किया जा सकता है। यहाँ एक काल्पनिक उदाहरण है:

func example() (*int, error) {
    var err error

    on err != nil {
        return nil, err
    }

    foo, err = calcThis()

    on err != nil {
        return &foo, err
    }

    foo, err = calcThat(&foo)

    return
}

मेरी नज़र में, यह गो की शैली और पठनीयता को बरकरार रखता है, जबकि यह स्पष्ट करता है कि प्रत्येक चरण में क्या हो रहा है (एक बार जब आप प्रतिमान को समझते हैं), क्योंकि यह err सेट होने की प्रत्येक घटना के बाद उस स्थिति को प्रभावी ढंग से सम्मिलित कर रहा है।

आप निम्न कार्य भी कर सकते हैं:

func example() (foo int, err error) {
    var message string

    on err != nil {
        return foo, errors.Wrap(err, message)
    }

    message = "failed to calc this"
    foo, err = calcThis()

    message = "failed to calc that"
    foo, err = calcThat(foo)

    return
}

अंत में, इसमें त्रुटि प्रबंधन से परे प्रयोज्यता है। अगर foo == 0 वापस लौटना चाहते हैं? एक और काल्पनिक उदाहरण:

func example(i int) bool {
    on x == 0 {
        return false
    }

    x = calcSomeInt(i)
    return true
}

@cstockton

मैं इसका विरोध करने वाला था कि इस तरह से त्रुटियों को दूर करना थोड़ा आसान होगा, लेकिन:

• यह पहले से ही एक "गॉचा" है जिसमें ऐसे फ़ंक्शन हैं जो _only_ त्रुटियां लौटाते हैं, जैसे कि json.Unmarshal । IME अच्छे कोड समीक्षक इसे बहुत जल्दी देखना सीख जाते हैं।
• यह अभी भी फ़ंक्शन में एक सिंटैक्स त्रुटि होगी जो त्रुटि मान नहीं लौटाती है, जैसे कि http.Handler विधियाँ।
• यदि आप जानते थे कि त्रुटि को कैसे संभालना है, तो आप इसके बारे में सोच रहे होंगे, आप इसका अनुमान लगाएंगे, और आप शायद त्रुटि मान को वैसे भी कैप्चर करेंगे _ ताकि_ आप इसे संभाल सकें।
• यदि आपका इरादा किसी और की समस्या (कॉलर की) बनाने के लिए आने वाली किसी भी त्रुटि को वापस पास करना था, तो यह उस छोटे से नकारात्मक पक्ष के साथ पूरा करता है कि आप संदर्भ के लिए अधिक एनोटेशन पर स्पष्ट रूप से निपटने का अवसर चूक जाते हैं।

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

मुझे आशा है कि यह प्रतिक्रिया देने का सही तरीका है और मैं कोई प्रतिबद्ध नहीं हूं
गंभीर गलत-पास।

7/1/19 को, क्रिस स्टॉकटन नोटिफिकेशन @github.com ने लिखा:

@ianlancetaylor क्या किसी ने समर्थन करने के लिए ":=" ऑपरेटर को बढ़ाने का सुझाव दिया है
"अनुमानित रिटर्न" - मूल रूप से बिना किसी फ़ंक्शन के प्रयास के रूप में व्यवहार करें
बुलाना। [...]

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

लुसियो।

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

@griesemer मैं सहमत नहीं हूँ। हालांकि यह कीस्ट्रोक्स को सहेज सकता है, पॉइंटर अंकगणित को इस आधार पर गो से बाहर रखा गया था कि यह खराब, टूटे हुए कोड को लिखना आसान बनाता है। मुझे लगता है कि यह उसी प्रकार की विशेषता है जिससे बग का पता लगाना अधिक कठिन हो जाएगा।

data := try(ioutil.ReadAll(try(os.Open("foo.txt"))))

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

data := try(ioutil.ReadAll(try(http.Get("http://example.com/")).Body))

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

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

@ jesse-amano असाइनमेंट ऑपरेटर का उपयोग करना वास्तव में इस मामले को संभव होने से रोकता है, एक स्पष्ट असाइनमेंट स्टेटमेंट के बिना नीचे जैसा वे आज करते हैं, वैसा ही व्यवहार करते हैं:

json.Unmarshal(...)
(http.Handler)(h).ServeHTTP(w, r)

उन मानों के लिए जो केवल एक त्रुटि लौटाते हैं, return json.Unmarshal(...) तरह लौटाए जाने के योग्य हैं और इसे अधिक कॉम्पैक्ट रूप में भी प्रदर्शित किया जा सकता है क्योंकि if ब्लॉक के बाहर किसी मान की कोई आवश्यकता नहीं है।

if err := json.Unmarshal(...); err != nIl {
    return err
} 

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

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

संपादित करें: @ जेसी-अमानो मैं आपकी बात को पूरी तरह से याद करता हूं क्षमा करें! मुझे लगता है कि एक ऐसे फ़ंक्शन के अंदर होना जो कोई त्रुटि नहीं लौटाता है, एक सामान्य असाइनमेंट गिनती बेमेल संकलन त्रुटि प्रदर्शित करेगा? मुझे लगता है कि कोशिश शायद उसके लिए एक नए प्रकार का कंपाइलर त्रुटि संदेश पेश करेगी।

@beoran https://github.com/golang/go/issues/32825#issuecomment -507126700 के बारे में: त्रुटि प्रबंधन पहले से ही स्थिति से अलग है: कभी-कभी हम त्रुटि को अपरिवर्तित करते हैं, कभी-कभी हम एक सजाए गए त्रुटि को वापस करते हैं, कभी-कभी हम कार्य करते हैं एक त्रुटि पर, और कभी-कभी हम (सही ढंग से) एक त्रुटि को अनदेखा कर सकते हैं। केवल एक चीज जो वे सभी साझा करते हैं (सिवाय जब हम त्रुटि को अनदेखा करते हैं) err != nil परीक्षण है (जिसे हम पहले से ही एक से अधिक तरीकों से कर सकते हैं)। इन सभी मामलों (या उनमें से 95%) को पकड़ने के लिए एक नई भाषा सुविधा के लिए जितना अच्छा होगा, इस तरह के निर्माण से हमारे पास पहले से मौजूद अन्य नियंत्रण संरचनाओं के साथ गैर-ऑर्थोगोनल तरीकों में हस्तक्षेप करने की अत्यधिक संभावना है। यानी, हम इनमें से कुछ मामलों (शायद 20%, शायद 50%) को बेहतर बनाने की उम्मीद कर सकते हैं।

@cstockton https://github.com/golang/go/issues/32825#issuecomment -507136111 के बारे में: यदि नेस्टेड try केवल सड़क ब्लॉक शेष हैं और go vet पर्याप्त नहीं है , मुझे लगता है कि हम नेस्टेड try अस्वीकार करने पर विचार कर सकते हैं - यह काफी आसान होगा। लेकिन फिलहाल मुझे लगता है कि हम अभी भी FUD (भय, अनिश्चितता और संदेह) के चरण में हैं, व्यावहारिक रूप से किसी ने भी वास्तव में try गंभीरता से प्रयोग नहीं किया है। मैं नोट करता हूं कि जिन लोगों ने ऐसा किया है, उनकी रिपोर्ट पॉजिटिव आई है।

पुनश्च: try मुद्दा प्रतिक्रिया के लिए फिर से खुला है। चलो वहाँ पर जारी रखें।

@cstockton ओह, बिल्कुल। स्पष्ट करने के लिए, मैं जिस बिंदु के लिए जा रहा था वह यह था कि अधिकांश मामलों में त्रुटि मान को कैप्चर किए बिना json.Unmarshal जैसे कार्यों को कॉल करने के लिए यह _ पहले से ही खराब अभ्यास है, लेकिन आमतौर पर इसके बजाय defer file.Close() लिए बुरा अभ्यास नहीं माना जाता है defer func() { err = file.Close(); if err != nil { ... }; }() , और हमने बहुत आसानी से अंतर बताना सीख लिया। तो यह (शायद) आपके प्रस्तावित परिवर्तन के साथ होगा। जब मैं त्रुटि को संभालने का इरादा रखता था, तो मैंने शुरुआत में foo := strconv.ParseFloat(bar, 64) का निर्दोष रूप से उपयोग करने के बारे में सोचा, लेकिन संक्षिप्त विचार के बाद मुझे नहीं लगता कि यह वास्तव में एक समस्या है।

@sirkon https://github.com/golang/go/issues/32825#issuecomment -507167388 के संबंध में: कृपया ऐसे स्पष्ट रूप से अयोग्य बयानों को चर्चा से बाहर कर दें - उनका यहां कोई स्थान नहीं है। सिर्फ रिकॉर्ड के लिए, गो में कई विचार वास्तव में 60 के दशक के बजाय 80 के दशक (पैकेज, अलग संकलन, आदि) से हैं और कई बहुत छोटे हैं (गोरआउटिन, इंटरफेस)। ये विचार अभी भी पुराने लग सकते हैं, लेकिन वे समय की कसौटी पर खरे उतरे हैं (कम से कम सीएस के आसपास कम समय रहा है)।

@turtleDev https://github.com/golang/go/issues/32825#issuecomment -507231353 के बारे में: गो अपवाद हैंडलिंग करता है, और यह panic और defer और recover - हम इसे "अपवाद प्रबंधन" नहीं कहते हैं क्योंकि यह शब्द एक ऐसे अर्थ के साथ आता है जो गो के लिए भ्रामक है। लेकिन स्पष्ट होने के लिए, गो वह सब कर सकता है जो raise साथ try-catch कर सकता है, और भी बहुत कुछ (क्योंकि try-catch विपरीत, defer का उपयोग किया जा सकता है सशर्त)। धन्यवाद।

@sorenvonsarvort https://github.com/golang/go/issues/32825#issuecomment -507268293 के संबंध में: यदि आप प्रत्येक मामले के लिए अलग त्रुटि सजावट चाहते हैं, तो if कथन का उपयोग करें। कृपया डिज़ाइन दस्तावेज़ देखें। इस सवाल का जवाब अब तक कई बार मिल चुका है। धन्यवाद।

@cstockton https://github.com/golang/go/issues/32825#issuecomment -507306652 के बारे में: हां, हमने ऐसी व्यवस्था के बारे में सोचा है। विशेष रूप से, हमने "तालिकाओं को चालू करने" के बारे में सोचा है और try प्रदान करने के बजाय, केवल handle , जो एक त्रुटि हैंडलर घोषित करता है। यदि कोई हैंडलर मौजूद है (और केवल तभी), तो कोई असाइनमेंट के एलएचएस में err को छोड़ देगा, और इसे स्पष्ट रूप से चेक किया जाएगा (जैसे एक अदृश्य try )। यह अच्छा दिखता है, लेकिन यह पूरी तरह से अदृश्य भी है, जो एक बड़ा लाल झंडा है। हम चाहते हैं कि अपवाद हैंडलिंग कोड में हर जगह स्पष्ट रूप से दिखाई दे। इसके बिना, कोड को पढ़ना और यह देखना लगभग असंभव होगा कि त्रुटि जाँच कहाँ हो रही है।

@griesemer स्पष्टीकरण के लिए धन्यवाद। लेकिन पैनिक और रिकवर के अलग-अलग उपयोग के मामले हैं और अधिकांश भाग के लिए किसी भी प्रोडक्शन कोड बेस में खोजना बहुत कठिन है। जो आपको प्रवाह निर्माणों के केवल सीमित मात्रा में नियंत्रण के साथ छोड़ देता है। एक नया निर्माण जोड़ने से वह स्थिरता टूट जाएगी क्योंकि अब आपके पास प्रवाह निर्माण का एक नया नियंत्रण है जो वापसी जैसा कुछ करता है।

@ मैथ्यू-नोकेन https://github.com/golang/go/issues/32825#issuecomment -507323973 के बारे में: आप एक दिलचस्प विचार का प्रस्ताव कर रहे हैं; यह काफी हद तक डिबगर के वॉच पॉइंट मैकेनिज्म जैसा दिखता है। ऐसे कुछ प्रश्न हैं जिनका उत्तर देना होगा: क्या on ब्लॉक को वापस लौटना है (मुझे ऐसा संदेह है, क्योंकि अन्यथा आप स्पेगेटी कोड भूमि में आ जाते हैं)? क्या एक से अधिक ऐसे on स्टेटमेंट हो सकते हैं? on स्थिति कितनी जटिल हो सकती है (प्रत्येक असाइनमेंट पर इसका मूल्यांकन करना होगा)? ध्यान दें कि हमारे पास मनमानी अभिव्यक्ति नहीं हो सकती क्योंकि हमें on कथन के साथ विशिष्ट रूप से चर की पहचान करनी है। इसके अलावा, गो में कुछ हद तक एक अभिशाप: on निर्माण का तात्पर्य अदृश्य कोड को कहीं और निष्पादित करने के लिए है।

यदि आप इसे और अधिक एक्सप्लोर करना चाहते हैं, तो मैं इसे कहीं और चर्चा करने का सुझाव देता हूं (गोलंग-नट्स, या एक अलग, नया प्रस्ताव)। धन्यवाद।

@as https://github.com/golang/go/issues/32825#issuecomment -507345821 के संबंध में:

पॉइंटर अंकगणित को इस आधार पर गो से बाहर रखा गया था कि यह खराब, टूटे हुए कोड को लिखना आसान बनाता है

दरअसल, इसे बाहर रखा गया था क्योंकि इससे कचरा संग्रहण मुश्किल या असंभव हो जाता था (और हां, कोई भी असुरक्षित कोड भी लिख सकता है)। लेकिन यहां अधिक महत्वपूर्ण बात यह है कि इस निर्णय का समर्थन करने वाले ठोस सबूत और अनुभव थे।

अभी तक कोई अनुभव नहीं है और कोई सबूत नहीं है कि नेस्टेड try प्रचलित या आम होने जा रहे हैं। लेकिन https://github.com/golang/go/issues/32825#issuecomment -507358397 देखें।

@turtleDev https://github.com/golang/go/issues/32825#issuecomment -507368167 के बारे में: एक panic _exactly_ एक अपवाद है, और recover एक आस्थगित फ़ंक्शन के अंदर अनिवार्य रूप से एक catch । उत्पादन कोड में उन्हें खोजना कठिन हो सकता है क्योंकि गो में हम आपको अपवादों का उपयोग करके अपना कोड लिखने की अनुशंसा नहीं करते हैं; उनका उपयोग केवल असाधारण परिस्थितियों में किया जाना चाहिए।

नियंत्रण प्रवाह संरचनाओं की संख्या के संबंध में: प्रस्ताव बहुत स्पष्ट है कि try केवल वाक्यात्मक चीनी है, और कुछ नहीं।

मैंने इस सूत्र में इस सूत्र में हाल की कुछ टिप्पणियों का उत्तर देने का प्रयास किया है। लेकिन आइए वास्तविक try अंक #32437 में try प्रस्ताव पर नई टिप्पणियां जारी रखें (अब आज के रूप में फिर से अनलॉक); और इस मुद्दे को leave err != nil alone चर्चा के लिए आरक्षित छोड़ दें। धन्यवाद।

@cstockton https://github.com/golang/go/issues/32825#issuecomment -507306652 के बारे में एक और टिप्पणी: अगर हमने इसे लागू किया है, तो इसके साथ शुरू करें

    func f() int { ... }
    ...
    x := f()

और बदल रहा है

    func f() (int, error) { ... }

इसका मतलब यह होगा कि x := f() का व्यवहार अचानक और चुपचाप बहुत अलग होगा।

मैंने हमारे सभी गो रिपॉजिटरी पर @lpar के समान कुछ प्रयोग किए। परिणाम इस सार में हैं: https://gist.github.com/freeformz/55abbe5da61a28ab94dbb662bfc7f763

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

func f() int { ... }
func a() error {
    x := f() // if f() is updated to return an error, we get automatic error propagation by default
    ...
}

func b() {
    x := f() // if f() is updated to return an error, we get the same compiler error 
    // assignment mismatch: 1 variable but pkg.f returns 2 values
}

मुझे लगता है कि आम मामले में यह इस दृष्टिकोण के लिए एक अच्छा लाभ है, कोने के मामले जहां यह एक समस्या पैदा करता है, मेरा मानना ​​​​है कि पहले से ही भंगुर हैं। केवल एक ही मैं सोच सकता हूं कि वास्तव में बुरा हो सकता है एक म्यूटेक्स को डेडलॉक कर रहा है:

func (t *T) a() error {
   t.mu.Lock()
   x := f() // if f() is updated to return an error, we get automatic error propagation by default
   if x > 15 {
     t.mu.Unlock()
     return errors.New("t > 15")
   }
   ...
}

लेकिन मुझे लगता है कि इस तरह लिखा गया कोड पहले से ही डेडलॉक्स के लिए अतिसंवेदनशील है यदि यह वैध प्रोग्राम स्थिति में सफल होने के लिए विदेशी लाइब्रेरी कॉल पर निर्भर करता है। यदि इसे ऐसे दायरे में संग्रहीत किया जाता है जो आतंक से परे रह सकता है तो यह गतिरोध कर सकता है यदि वही पुस्तकालय एनपीई के माध्यम से रनटाइम पैनिक पेश करता है। इसके अलावा इस तरह के कोड लिखने के लिए एक मुख्य प्रेरक ढेर पर रहने वाले defers की ऐतिहासिक लागत है। स्टैक पर रहने वाले सिंगल-डिफर्स के प्रदर्शन में सुधार के साथ ऐसा कोड वास्तव में आवश्यक नहीं है। मुझे लगता है कि इस प्रकार की त्रुटि की किसी भी व्युत्पत्ति को आसानी से दूर किया जा सकता है।

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

@griesemer

नियंत्रण प्रवाह संरचनाओं की संख्या के संबंध में: प्रस्ताव बहुत स्पष्ट है कि कोशिश केवल वाक्य रचनात्मक चीनी है, और कुछ नहीं।

मुझे क्षमा करें, लेकिन try मैक्रो (जैसे सी) नहीं होगा, इसलिए वास्तव में, अंतिम उपयोगकर्ता के लिए यह प्रवाह विवरण का एक और नियंत्रण है।

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

फिर, ये मेरे विचार हैं और मैं उनका प्रतिनिधित्व कर रहा हूं। मुझे यकीन है कि गो टीम ने इस पर पहले से कहीं अधिक विचार किया है।

साइड: यह मुझे अजीब लगता है कि इस मुद्दे पर 1335 अपवोट हैं जबकि try प्रस्ताव (#32437) में केवल 279 डाउनवोट हैं। मैं उम्मीद करता हूं कि इसे पसंद करने वाले लोग try प्रस्ताव को कम करें ताकि इसके बारे में समुदाय की भावनाएं अधिक स्पष्ट हों, क्योंकि ये दोनों प्रस्ताव परस्पर अनन्य हैं।

@griesemer

त्रुटि प्रबंधन पहले से ही स्थिति से अलग है: कभी-कभी हम त्रुटि को अपरिवर्तित लौटाते हैं, कभी-कभी हम एक सजाए गए त्रुटि को वापस करते हैं, कभी-कभी हम एक त्रुटि पर कार्य करते हैं, और कभी-कभी हम (सही ढंग से) किसी त्रुटि को अनदेखा कर सकते हैं।

वहाँ सहमत हूँ, इतना स्पष्ट है।

केवल एक चीज जो वे सभी साझा करते हैं (सिवाय जब हम त्रुटि को अनदेखा करते हैं) err != nil परीक्षण है (जिसे हम पहले से ही एक से अधिक तरीकों से कर सकते हैं)। इन सभी मामलों (या उनमें से 95%) को पकड़ने के लिए एक नई भाषा सुविधा के लिए जितना अच्छा होगा, इस तरह के निर्माण से हमारे पास पहले से मौजूद अन्य नियंत्रण संरचनाओं के साथ गैर-ऑर्थोगोनल तरीकों में हस्तक्षेप करने की अत्यधिक संभावना है। यानी, हम इनमें से कुछ मामलों (शायद 20%, शायद 50%) को बेहतर बनाने की उम्मीद कर सकते हैं।

प्रस्तावित try() कथन भी गैर-ऑर्थोगोनल तरीकों से if और return साथ "हस्तक्षेप" करता है, इसलिए मैं कहूंगा कि यह तर्क सही नहीं है। यहां कुछ लोग इसी कारण से try() को नापसंद करते हैं, लेकिन मैं असहमत हूं। गो ओबेरॉन नहीं है, यह सरल है लेकिन न्यूनतर नहीं है, गो अधिक व्यावहारिक है।

जहां हम असहमत हैं, यह एक भाषा निर्माण से परेशान होने के लायक भी है, जैसा कि आपने स्वयं स्वीकार किया है, केवल सीमित उपयोग और प्रयोज्यता है, और यह पहले से ही if और return साथ सही ढंग से किया जा सकता है। try() इतने अभिभूत हैं कि उनके पास यह बिल्कुल भी नहीं होगा। भले ही यह रिटर्न के साथ ऑर्थोगोनल न हो, एक अधिक शक्तिशाली, अधिक आम तौर पर उपयोगी try() शायद वही है जो अधिकांश गो प्रोग्रामर देखना चाहेंगे।

@beoran ,

आपने लिखा है कि आप एक "अधिक शक्तिशाली", "अधिक सामान्य रूप से उपयोगी" try() चाहेंगे।

@griesemer ने 4 स्थितियों का उल्लेख किया:

1. त्रुटि अपरिवर्तित लौटाएं
2. एक सजाया हुआ त्रुटि लौटाएं
3. त्रुटि पर कार्रवाई
4. त्रुटि पर ध्यान न दें

try() डिजाइन द्वारा 1 हल करता है: यह सचमुच if err != nil { return ..., err } लिए एक शॉर्टकट है।

मौजूदा भाषा संरचनाएं 3 और 4 को हल करती हैं। हम पहले से ही if err != nil { ... } साथ एक त्रुटि पर कार्य कर सकते हैं और उस मामले में अधिक संक्षिप्त संरचना खोजना मुश्किल होगा। हम पहले से ही _ साथ एक त्रुटि को अनदेखा कर सकते हैं।

यह हमें 2 के साथ छोड़ देता है (एक सजाए गए त्रुटि को वापस करें)। try() प्रस्ताव त्रुटि को सजाने के लिए एक स्थगित कथन का उपयोग करने का सुझाव देता है, या यदि प्रत्येक त्रुटि को अलग तरह से सजाया जाना चाहिए तो मानक if err != nil { ... } निर्माण का उपयोग करें।

प्रस्ताव के इस भाग में तर्क को अच्छी तरह से समझाया गया है:

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

handler := func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
}

f := try(os.Open(filename), handler)              // handler will be called in error case

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

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

[...]

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

क्या आप इस तर्क से असहमत हैं?

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

इसके अलावा, अब, हम सभी 4 त्रुटि उपयोग मामलों को if err != nil कथन के साथ संभालते हैं, जिसे व्यापक रूप से समझा जाता है, संगत गो मुहावरा। केवल केस 1 के लिए try() का उपयोग करना, और संभवत: केस 2 के लिए, यदि हमें डिफर स्टेटमेंट में एरर रैपिंग करने के ओवरहेड पर कोई आपत्ति नहीं है, तो इसका मतलब है कि एरर हैंडलिंग के लिए कोड if में विभाजित हो जाएगा। try असंगत रूप से, और यदि त्रुटि प्रबंधन में परिवर्तन होता है, तो हमें एक और दूसरे के बीच स्विच करना होगा।

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

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

@beoran मुझे लगता है कि मामलों 1 और 2 में फ़ंक्शन से एक त्रुटि (क्रमशः बिना और सजावट के साथ) वापस करने के लिए आम है, जबकि मामले 3 और 4 नहीं (क्रमशः एक त्रुटि पर कार्य करते हैं और एक त्रुटि को अनदेखा करते हैं)। मुझे लगता है कि 'कोशिश ()' मामलों 1 और 2 पर ध्यान केंद्रित है।

क्या होगा यदि try() प्रस्ताव को 1 और 2 मामलों को संभालने के लिए वैकल्पिक हैंडलर फ़ंक्शन को स्वीकार करके सुधार किया जा सकता है? बेशक, इसके लिए प्रस्ताव में सूचीबद्ध प्रश्नों के उचित उत्तर खोजने की आवश्यकता है, लेकिन यह ट्रैक्टेबल लगता है। क्या आप ऐसा कुछ समर्थन करेंगे?

यहाँ मुझे बाहर। यदि ऐसा है तो हम चाहते हैं कि उपयोगकर्ता त्रुटियों की जाँच करें, हमें संभवतः जाँच की गई त्रुटियाँ (जैसे जाँच किए गए अपवाद) जोड़नी चाहिए। इस तरह हम यथासंभव स्पष्ट हैं और उपयोगकर्ता जानता है कि वे सभी त्रुटियों की जांच कर रहे हैं।

पूरी गंभीरता से, अगर इन निर्णयों को करने के पीछे मैं ही होता, तो मैं वास्तव में कोटलिन ? ऑपरेटर या जंग unwrap() व्यवहार जैसी किसी चीज़ का पुनर्व्यवस्थित करना चाहूंगा।

इनमें से कोई भी मुझे लगता है कि एक सुधार होगा:

getFile()?.getPath()?.toString()

जहां रास्ते में कोई त्रुटि होने पर आपको nil वापस मिलता है या

get_file().unwrap().get_path().unwrap().lossy_to_string()

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

7/2/19 को, निकोलस ग्रिली नोटिफिकेशन @github.com ने लिखा:

@beoran मुझे लगता है कि मामले 1 और 2 में एक त्रुटि वापस करने के लिए आम है
समारोह (क्रमशः बिना और सजावट के साथ), जबकि मामले 3 और 4
न करें (क्रमशः एक त्रुटि पर कार्य करें और एक त्रुटि को अनदेखा करें)। मुझे लगता है कि 'कोशिश करें ()'
केस 1 और 2 पर फोकस है।

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

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

मामले 1 और 2, मेरी राय में, "असफल" कमांड द्वारा बेहतर सेवा प्रदान करते हैं
कीवर्ड जो स्पष्ट रूप से इंगित करता है (कुछ को इसकी आदत हो जाने के बाद) a
कार्यक्रम प्रवाह में परिवर्तन और जो किसी के अधीन नहीं है
असुविधाजनक परंपरा इसके पूर्ण वाक्य रचना के संबंध में।

इससे क्या होता है, हालाँकि, हम इसे पसंद करते हैं या नहीं, यह है कि
अंतिम रिटर्न पैरामीटर के रूप में "गलती" की स्थिति जल्द ही है
कन्वेंशन के बजाय कानून बनें। यह कई "अनपेक्षित" or . में से एक है
"संपार्श्विक" परिणाम जिन्हें ध्यान में रखा जाना चाहिए।

ऐसे और भी कई परिणाम होंगे, न्यूनतम से लेकर . तक
विनाशकारी, कुछ जो केवल अवसरवादी रूप से गुल्लक में हैं
प्रस्ताव। मैं व्यक्तिगत रूप से सावधानी के पक्ष में गलती करूंगा, मैं करता हूं
समझें कि गो टीम और रॉबर्ट विशेष रूप से क्यों मांग कर रहे हैं
समर्थन और निस्संदेह चोट लगी है कि प्रतिरोध इतना निकला
महान।

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

@lootch क्या आपको काम करने के लिए try लिए अंतिम रिटर्न पैरामीटर होने की आवश्यकता त्रुटि के साथ कोई विशेष चिंता है? क्या यह पहले से ही एक वास्तविक सम्मेलन नहीं है?

(एक तरफ के रूप में, हम प्रतिरोध के बारे में "आहत" नहीं हैं - ज्यादातर बाहरी प्रतिक्रिया के बारे में चिंतित हैं।)

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

मैं बस एक त्वरित टिप्पणी लिखना चाहता हूं जिसमें कहा गया है कि बहुत सारे गो लिखे हैं (मैं 200 9 में अपनी पहली सार्वजनिक रिलीज के बाद से गो का उपयोग कर रहा हूं - मेरा जीथब देखें) मैं त्रुटि प्रबंधन के आसपास एर्गोनॉमिक्स में सुधार का स्वागत करता हूं

मैं इस पर काफी नाराज हो गया था कुछ साल पहले मैंने वास्तव में घबराहट के आसपास कुछ चीनी लिखी थी और उन्हें अनियंत्रित अपवादों की तरह (ज्यादातर) काम करने की अनुमति देने के लिए पुनर्प्राप्त किया था: https://hackthology.com/exceptions-for-go-as-a-library । एचटीएमएल । वास्तव में उन रैपरों का उपयोग करना एक बुरा विचार है क्योंकि समुदाय मौजूद है। हालांकि, मुझे विश्वास है कि त्रुटि प्रबंधन के आसपास एर्गोनॉमिक्स में सुधार करना एक जीत है।

यह पागल लगता है कि लोग एक अत्यंत क्रियात्मक लेकिन अनुपयोगी तरीके से त्रुटि की स्थिति को प्रचारित करने के लिए जोरदार बहस कर रहे हैं। मैंने अपने कोड (और अन्य कोड) में वास्तविक बग्स को लिखा और पाया है जहां लोगों ने if err != nil शर्त को गड़बड़ कर दिया है और बग्स बनाए हैं। उन बगों के कभी लिखे जाने का वास्तव में कोई कारण नहीं है। स्थैतिक जाँच मदद कर सकती है लेकिन इन बगों को खत्म नहीं कर सकती।

मैं त्रुटि प्रबंधन के इर्दगिर्द एर्गोनॉमिक्स में सुधार के प्रस्तावों का समर्थन करता हूं।

प्रस्ताव प्रक्रिया https://golang.org/s/proposal , "प्रपोज़िंग चेंजेस टू गो" को उद्धृत करने के लिए है।
यह समस्या किसी बदलाव का प्रस्ताव नहीं कर रही है, इसलिए वास्तव में यह एक श्रेणी की त्रुटि है।
अगर किसी ने "अकेले छोड़ो" शीर्षक से एक प्रस्ताव दायर किया है, तो हम इसे प्रस्ताव के रूप में बंद कर देंगे।

लेकिन वास्तव में यह मुद्दा #32437 जैसे अन्य मुद्दों की चर्चा का सिर्फ एक विस्तार है, इसलिए मैं इसे "कुछ न करें" पर चर्चा करने के लिए एक अच्छी जगह के रूप में खुला छोड़ दूंगा।

मैंने इसे यह इंगित करने के लिए प्रस्ताव-होल्ड चिह्नित किया है कि यहां कोई विशिष्ट निर्णय नहीं है, अधिक मेटा-निर्णय।

साइड: यह मुझे अजीब लगता है कि इस मुद्दे पर 1335 अपवोट हैं जबकि try प्रस्ताव (#32437) में _only_ 279 डाउनवोट हैं।

जब तक मुझे इसके बारे में पता चला, तब तक प्रयास प्रस्ताव को बंद कर दिया गया था, इसलिए मैं इसे कम नहीं कर सका। मुझे लगता है कि इसलिए भी इस प्रस्ताव को शुरू करने के लिए दर्ज किया गया था।

7/2/19 को रॉबर्ट ग्रिसेमर नोटिफिकेशन @github.com ने लिखा:

@lootch क्या आपको अंतिम होने की आवश्यकता के साथ त्रुटि के साथ कोई विशेष चिंता है
काम करने के लिए try लिए वापसी पैरामीटर? क्या यह पहले से ही वास्तविक नहीं है
सम्मेलन?

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

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

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

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

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

सबसे बढ़कर, मुझे लगता है कि इस तिल से बना पहाड़ है
यह दर्शाता है कि गो जीवन बदलने वाले मील के पत्थर तक पहुंच गया है। लगभग
निश्चित रूप से, 2013 में जो धारणाएँ सच थीं, वे अब अच्छी नहीं हो सकती हैं
पकड़। ऐसा नहीं है कि यह किसी के लिए खबर है, लेकिन यह सुझाव देता है कि Go2 हो सकता है
Go1 के साथ पीछे की ओर संगत होना उतना अद्भुत नहीं है जितना कि रहा है
बहुत दृढ़ता से प्रस्तावित (मेरी राय में)।

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

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

यह अभी भी मेरे लिए बहुत आश्चर्य की बात है कि एक बहुत ही मामूली सहायक फ़ंक्शन जोड़ने के बारे में इतना हंगामा है कि हर कोई अनदेखा करने के लिए स्वतंत्र है, फिर भी लोग महत्वपूर्ण भाषा परिवर्तनों पर गंभीरता से विचार कर रहे हैं जैसे on error जो वास्तव में एक विशिष्ट शैली का दृढ़ता से सुझाव देते हैं भाषा में त्रुटि प्रबंधन के संबंध में।

आपके इनपुट के लिए फिर से धन्यवाद। यह सब बहुत दिलचस्प है।

मुझे यकीन नहीं है कि यह प्रस्ताव इस पर चर्चा करने के लिए सही जगह है, लेकिन इस धागे में कोशिश कीवर्ड पर पहले से ही एक विशद चर्चा है, मैं इसे अभी के लिए विषय पर विचार करूंगा :)

मुझे आश्चर्य है कि क्या Google लोग अपने आंतरिक गोलंग रेपो में कोशिश कीवर्ड को लागू करने के इच्छुक होंगे, और बाद में उस कीवर्ड का उपयोग करने के लिए मौजूदा Google कोड बेस को परिवर्तित कर देंगे। इसे केवल आंतरिक रखते हुए, यह इसे आसानी से वापस करने की अनुमति देगा (अर्थात, बोझ एक ही कंपनी पर है, न कि पूरे समुदाय पर)।

यह वास्तविक दुनिया के हाई-स्लोक कोड बेस में इस सुविधा पर थोड़ा केस स्टडी करने की अनुमति देगा। फेसबुक ने अतीत में PHP सुविधाओं के साथ कुछ ऐसा ही किया है, और इस तरह वे बड़े पैमाने पर समुदाय को प्रस्तावित करने से पहले कुछ कार्यक्षमता को ठीक करने में सक्षम थे।

यदि आप एक केस स्टडी लिखना चाहते हैं कि कैसे try कीवर्ड का उपयोग _in practice_ में किया गया और वास्तविक जीवन में इसका क्या मूल्य जोड़ा गया, तो यह एक सम्मोहक मामला प्रदान कर सकता है। यदि यह (काल्पनिक रूप से) कोई वास्तविक विश्व मूल्य प्रदान नहीं करेगा, तो यह भी जानना मूल्यवान होगा। कभी-कभी कुछ कागज पर वास्तव में अच्छा लगता है लेकिन व्यवहार में काम नहीं करता है - या इसके विपरीत।

@Freeaqingme हमने पहले ही एक अस्थायी CL तैयार कर लिया है जो दिखाता है कि try एसटीडी लाइब्रेरी में कैसा दिख सकता है: https://go-review.googlesource.com/c/go/+/182717 (इसमें गलत हो सकता है) सकारात्मक, लेकिन अगर हैं, तो वे बहुत दुर्लभ हैं)। हम शायद एक ऐसा उपकरण विकसित करने पर विचार कर रहे हैं जो दोनों दिशाओं में कोड बेस के रूपांतरण की अनुमति देता है।

आपको अपने कोड आधार में tryhard का उपयोग करने और वापस रिपोर्ट करने के लिए भी प्रोत्साहित किया जाता है।

धन्यवाद।

@griesemer मैंने खुद को स्पष्ट नहीं किया होगा। मुझे लगता है कि Google आंतरिक रूप से गो के अपने स्वयं के निर्माण का उपयोग करता है। मेरा सुझाव यह होगा कि आप ऊपर लिंक किए गए पैच को आंतरिक Google बिल्ड में लागू करें, और फिर Google कोड बेस को परिवर्तित करें (भागों के) - न केवल stdlib, बल्कि विशेष रूप से आंतरिक प्रोजेक्ट जो गो में लिखे गए हैं। यदि Google इंजीनियर वास्तविक जीवन की स्थितियों में कुछ महीनों के लिए इसका उपयोग करते हैं, तो यह अच्छी अंतर्दृष्टि प्रदान करेगा कि यह व्यवहार में कैसे काम करेगा।

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

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

@Freeaqingme समझ गया। हम निश्चित रूप से आंतरिक रेपो पर try चला सकते हैं। मुझे यकीन नहीं है कि हम रूपांतरण कर सकते हैं और वापस परिवर्तित कर सकते हैं - यहां एक महत्वपूर्ण लागत शामिल है। साथ ही, हम इस प्रयोग पर केवल समग्र (आंकड़े) रिपोर्ट कर सकते हैं क्योंकि हम आंतरिक विवरण पर रिपोर्ट करने में सक्षम नहीं होंगे। यही कारण है कि समुदाय के पास हमारे दावों को सत्यापित करने का कोई आसान तरीका नहीं होगा। अंत में, Google का कोड आधार प्रतिनिधि नहीं हो सकता है।

लेकिन धन्यवाद, बिंदु लिया।

@griesemer मैं सराहना करता हूं कि यह एक महंगा प्रयास हो सकता है। ऐसे में मैं ऐसा नहीं करूंगा। यदि यह केवल आपके ट्राइहार्ड प्रोजेक्ट को लागू करने की बात है तो लागत सीमित हो सकती है। लेकिन वास्तव में यह निर्धारित करने के लिए एक Googler (जो मैं नहीं हूं) के लिए कुछ है।

मैं समझता/समझती हूं कि आप अलग-अलग Google प्रोजेक्ट या आंतरिक अवसंरचना पर रिपोर्ट करने में सक्षम नहीं होंगे। हालाँकि, कुछ किस्से साझा किए जा सकते हैं, शायद। लेकिन जो कुछ मुझे व्यक्तिगत रूप से अधिक मूल्यवान लगेगा, वह यह है कि कुछ Googler रिपोर्ट कर रहे हैं कि यह उनके लिए कैसे काम करता है। विवरण में जाने के बिना, "मुझे एक्स की उम्मीद थी लेकिन जब मैं ए और बीआई जैसे मामलों में भाग गया तो पाया कि वाई" मुझे बहुत मूल्यवान लगेगा। मुझे उस तरह की रिपोर्ट को सत्यापित करने की शून्य आवश्यकता मिलेगी।

अंत में, Google का कोड आधार प्रतिनिधि नहीं हो सकता है।

हो सकता है, नहीं भी हो सकता है। लेकिन Google पर बहुत सारे लोग काम कर रहे हैं, इसलिए मुझे लगता है कि अधिकांश कोड आधार इस पर आधारित नहीं है कि किसी एक व्यक्ति ने इसे कैसे लिखने का फैसला किया, बल्कि कई अलग-अलग योगदानकर्ताओं (कर्मचारियों) के योगदान की परिणति हो। उस संबंध में मुझे उम्मीद है कि चीजें उतनी ही प्रतिनिधि के रूप में होंगी जितनी चीजें मिल सकती हैं। शायद 100% प्रतिनिधि कोड आधार जैसी कोई चीज़ नहीं है।

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

एक नया सिंटैक्स पेश करने का मतलब है कि हर किसी को अपने गो संस्करण को अपग्रेड करना होगा। मैं अभी भी गो 1.10 का उपयोग कर रहा हूं क्योंकि मेरा वर्कफ़्लो इस तथ्य पर आधारित है कि मैं go get चीजें कर सकता हूं और फिर कमांड लाइन से उनका उपयोग कर सकता हूं (मेरा GOPATH मेरे PATH ) . मॉड्यूल का उपयोग करने वाले किसी और की लाइब्रेरी go get कोशिश करते समय मुझे हाल ही में एक समस्या हुई थी। मुझे एक त्रुटि मिली कि .../v2 उपलब्ध नहीं था। इसका मतलब है कि कोड में पहले से ही एक विभाजन है (पायथन 2 और 3 सोचें)। मेरे लिए गो 1.11 से पहले और गो 1.11 के बाद एक दुनिया है। यह बहुत कष्टप्रद है और गो में त्रुटि प्रबंधन के साथ-साथ काम करने वाली किसी चीज़ के लिए एक नया सिंटैक्स पेश करना एक अच्छा व्यापार-बंद नहीं है। यह अधिक विखंडन का परिचय देता है।

7/4/19 पर, gonutz [email protected] लिखा है:

एक नया सिंटैक्स पेश करने का मतलब है कि हर किसी को अपने Go . को अपग्रेड करना होगा
संस्करण। मैं अभी भी गो 1.10 का उपयोग कर रहा हूं क्योंकि मेरा वर्कफ़्लो तथ्य पर आधारित है
कि मैं go get चीजें कर सकता हूं और फिर कमांड लाइन से उनका उपयोग कर सकता हूं (my
GOPATH मेरे PATH )। मुझे हाल ही में go get कोशिश करते समय एक समस्या हुई थी
किसी और की लाइब्रेरी जो मॉड्यूल का उपयोग करती है। मुझे एक त्रुटि मिली कि .../v2 था
नहीं हैहै। इसका मतलब है कि कोड में पहले से ही एक विभाजन है (सोचें
पायथन 2 और 3)। मेरे लिए गो 1.11 से पहले और गो 1.11 के बाद एक दुनिया है।
यह बहुत कष्टप्रद है और काम करने वाली किसी चीज़ के लिए एक नया सिंटैक्स पेश कर रहा है
साथ ही गो में एरर हैंडलिंग एक अच्छा ट्रेड-ऑफ बिल्कुल भी नहीं है। यह
अधिक विखंडन का परिचय देता है।

यदि यह कोई सांत्वना है, तो मैं बिल्कुल उसी स्थिति में हूं, जैसा कि एक है
मॉड्यूल जाओ। मुझे परिचित होने का समय और अवसर नहीं मिला
उनके साथ, इसलिए मैं Go1.10 के साथ भी जुड़ा हुआ हूं। शायद यही होना चाहिए
लायक एक सर्वेक्षण।

लुसियो।

--
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/golang/go/issues/32825#issuecomment -508372318

--
लुसियो डी रे
2 पीट रिट्रीफ St
केस्टेल (पूर्वी मुक्त राज्य)
9860 दक्षिण अफ्रीका

दूरभाष: +27 58 653 1433
सेल: +27 83 251 5824
फैक्स: +27 58 653 1435

मैं एक नया गोलंग डेवलपर हूं (अभी भी जाने के बारे में सीख रहा हूं)। मुझे लगता है कि वर्तमान त्रुटि प्रबंधन अच्छा है क्योंकि यह हमें आसानी से त्रुटि का प्रबंधन करता है। एक एंड्रॉइड डेवलपर के रूप में, मुझे लगता है कि गोलंग में if err != nil{ } तुलना में try-catch हमारी त्रुटि को प्रबंधित करना कठिन है। और मुझे लगता है कि स्पष्ट त्रुटि प्रबंधन हमेशा निहित त्रुटि प्रबंधन से बेहतर होता है।

पुनश्च. मेरी भाषा के लिए खेद है।

टूटा नहीं है....

मेम से प्यार करो, @ Daniel1984 :-)

संयोग से, try प्रस्ताव if err != nil अकेला छोड़ देता है; यह आपको सिर्फ एक अतिरिक्त विकल्प देता है जहां यह समझ में आता है।

मेरी राय है कि try को शामिल नहीं किया जाना चाहिए। try :

समर्थक

• प्रोग्रामर अपने द्वारा किए जाने वाले कीस्ट्रोक्स की संख्या कम करते हैं।
• प्रोग्रामर्स के पास वर्तमान फ़ंक्शन ए ला मैक्रो से लौटने के लिए एक शॉर्टहैंड हो सकता है।
• इसकी आवश्यकता नहीं है।
• यह आमतौर पर इस्तेमाल किया जाएगा।
• यह स्पष्ट है कि जादू कहाँ हो रहा है (जावा के throws विपरीत)।
• nil चेक के समुद्र को देखने पर अब आंखें नहीं चमकतीं।
• सरल कार्यान्वयन के साथ सबसे अच्छा काम करता है।

चोर

• try मौजूदा ऑपरेशन के लिए एक डुप्लिकेट विधि जोड़ता है।
• try लिए वर्तमान फ़ंक्शन से लौटने के लिए अप्रत्याशित है, एकेए अधिक जादू।
• यह त्रुटि जाँच में विसंगतियाँ जोड़ता है।
• बिना गो अनुभव वाले प्रोग्रामर समझ नहीं पाएंगे।
• त्रुटि प्रबंधन नहीं बदलता है।
• कम स्पष्टता (फ़ंक्शन रिटर्न और एक्सप्रेशन वैल्यू के बीच बेमेल)।
• try पर जो हो रहा है उसका शब्दों में वर्णन करना भी मुश्किल है।

@griesemer वही है जो मुझे पसंद नहीं है। चीजें सरल होनी चाहिए, मैं भाषा में जटिलता नहीं जोड़ना चाहता, बस एक ही चीज़ को प्राप्त करने के 2 तरीके हैं। इस if err != nil वर्बोसिटी से बचने के लिए पैटर्न हैं। https://www.ardanlabs.com/blog/2019/07/an-open-letter-to-the-go-team-about-try.html

Go2 प्रस्ताव #32437 if err != nil { return ... } बॉयलरप्लेट को कम बोझिल बनाने के लिए भाषा में नया सिंटैक्स जोड़ता है।

विभिन्न वैकल्पिक प्रस्ताव हैं: #32804 और #32811 मूल के रूप में सार्वभौमिक रूप से प्यार नहीं है।

मिश्रण में एक और विकल्प डालने के लिए: क्यों न इसे ऐसे ही रखा जाए ?

मुझे if err != nil निर्माण की स्पष्ट प्रकृति पसंद आई है और इस तरह मुझे समझ में नहीं आता कि हमें इसके लिए नए वाक्यविन्यास की आवश्यकता क्यों है। क्या यह सच में उतना बुरा है?

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

ऐसा लगता है कि एक बड़ा अंतराल है, लोगों ने केवल टिप्पणी करना शुरू कर दिया है
अभी और कोई यह धारणा बनाने में मदद नहीं कर सका कि यह ताज़ा है
उन्हें खबर.

इसे भी ध्यान में रखने की जरूरत है। अंगूर स्पष्ट रूप से ऐसा नहीं है
जितनी तेजी से कोई सोच सकता है।

लुसियो।

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

के बजाए:

एरर = माय फंक्शन ()
अगर गलती!= शून्य {
वापसी त्रुटि
}

अनुमति देना:

एरर = माय फंक्शन ()
अगर गलती!= शून्य {वापसी गलती}

संयोग से, कोशिश प्रस्ताव छोड़ देता है अगर गलती != nil अकेले; यह आपको सिर्फ एक अतिरिक्त विकल्प देता है जहां यह समझ में आता है।

यह सटीक औचित्य यह है कि गो कैसे एक और सी ++, सी #, स्काला, कोटलिन इत्यादि बन जाता है। "अगर आप नहीं चाहते हैं तो आपको इसका उपयोग करने की आवश्यकता नहीं है" यह है कि फीचर फूला हुआ भाषाएं कैसे बनती हैं।

संपादित करें - यह गलत तरीके से आया होगा। मैं यह नहीं कह रहा हूं कि try गो को एक फीचर फूला हुआ भाषा में बदलने जा रहा है। मैं कह रहा हूँ कि यहाँ औचित्य थोड़ा त्रुटिपूर्ण है

@deanveloper आपके पास "कोशिश" के साथ कठिन समझ त्रुटि व्यवहार का स्पष्ट उदाहरण है:
https://github.com/golang/go/issues/32437#issuecomment -498932961

भले ही यह थोड़ा दोहराव हो, मैं ओपी से सहमत हूं।
इसके अलावा, imo प्रस्तावित सभी विकल्प बेकार जटिलता का परिचय देते हैं।

जब आपके पास दायरे के अंदर केवल एक पंक्ति होगी तो घुंघराले ब्रैकेट को छोड़ना अच्छा होगा

@पागल हो जाना

इसका मतलब है कि कोड में पहले से ही एक विभाजन है (पायथन 2 और 3 सोचें)। मेरे लिए गो 1.11 से पहले और गो 1.11 के बाद एक दुनिया है।

मैं एक लंबे समय से पायथन प्रोग्रामर हूं और कथित "विभाजन" जिसका आप गो मॉड्यूल के बारे में उल्लेख करते हैं, पायथन 2 से पायथन 3 में प्रवासन की आपदा की तुलना में कुछ भी नहीं है।

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

try प्रस्ताव में एक अंतर्निहित कार्य है। यह पूरी तरह से पिछड़ा संगत है। यदि आपका कोड पहले से ही पहचानकर्ता के रूप में try का उपयोग करता है, तो आपका पहचानकर्ता try बिल्ट-इन को छाया देगा।

@pongsatornw

मुझे लगता है कि वर्तमान त्रुटि प्रबंधन अच्छा है क्योंकि यह हमें आसानी से त्रुटि का प्रबंधन करता है। एक एंड्रॉइड डेवलपर के रूप में, मुझे लगता है कि गोलंग में इरेट != nil{ } की तुलना में हमारी त्रुटि को प्रबंधित करना कठिन है। और मुझे लगता है कि स्पष्ट त्रुटि प्रबंधन हमेशा निहित त्रुटि प्रबंधन से बेहतर होता है।

क्या आपने प्रस्ताव को पूरा पढ़ा है? try सिर्फ एक अंतर्निहित फ़ंक्शन है जो if err != nil { return ..., err } की पुनरावृत्ति को दूर करने में मदद करता है। गो में त्रुटि प्रबंधन का सामान्य तर्क वही रहता है। यह अभी भी स्पष्ट है, त्रुटियां अभी भी मान हैं, और कोई कोशिश-पकड़ (उर्फ अपवाद) नहीं है।

@kroppt

• try मौजूदा ऑपरेशन के लिए एक डुप्लिकेट विधि जोड़ता है।

try सिर्फ दोहराए जाने वाले कोड को फैक्टर कर रहा है। यह append साथ समान है। हर बार जब हम तत्वों को एक स्लाइस में जोड़ते हैं तो हम इसे स्वयं लिख सकते हैं, लेकिन append को कॉल करना आसान है।

• यह त्रुटि जाँच में विसंगतियाँ जोड़ता है।

आप [...:...] का उपयोग करके "मैन्युअल रूप से" एक स्लाइस में हेरफेर कर सकते हैं या आप जो करते हैं उसके आधार पर आप append उपयोग कर सकते हैं। कोई विसंगति नहीं है। वे विभिन्न कार्यों के लिए सिर्फ अलग उपकरण हैं। त्रुटियों के लिए समान, एक सादे if err != nil { ... } , या try , हाथ में कार्य के आधार पर।

• try लिए वर्तमान फ़ंक्शन से लौटने के लिए अप्रत्याशित है, एकेए अधिक जादू।

यह अप्रत्याशित है क्योंकि यह नया है। हमें इसकी आदत हो जाती है क्योंकि हम इसका अधिक उपयोग करते हैं। और मुझे नहीं लगता कि यह जादू है; कोशिश की युक्ति बहुत सीधी है।

• बिना गो अनुभव वाले प्रोग्रामर समझ नहीं पाएंगे।
• try पर जो हो रहा है उसका शब्दों में वर्णन करना भी मुश्किल है।

बिना गो अनुभव वाले प्रोग्रामर समझ नहीं पाएंगे chan , defer , 'go , iota , आतंक , , वसूली करें इनमें से अधिकांश की तुलना में , type assertions, and many other things either without reading the documentation. try` आसान है।

• त्रुटि प्रबंधन नहीं बदलता है।

शायद यह एक अच्छी बात है, गोफर्स के अनुसार if err != nil अकेले छोड़ने के लिए कह रहे हैं ;-)

@marcopeereboom

स्पष्ट कोड सही कोड है। अपवाद संचालकों के साथ मैंने जो भयावहता देखी है, वह उस भयानक अपठनीय निर्माण से हमेशा के लिए दूर जाने के लिए पर्याप्त है।

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

@gale93

जब आपके पास दायरे के अंदर केवल एक पंक्ति होगी तो घुंघराले ब्रैकेट को छोड़ना अच्छा होगा

मुझे लगता है कि अधिकांश गोफरों का एक ही विचार था, और मैंने इश्यू ट्रैकर में इसी तरह के प्रस्तावों को कई बार पढ़ा। लेकिन यह try तुलना में बहुत बड़ा बदलाव है। केवल if कथन के लिए ऐसा करना उचित नहीं होगा। तो आपको इसे हर जगह बदलना होगा जहां एक ब्लॉक स्वीकार किया जाता है। ब्लॉक की शुरुआत को चिह्नित किए बिना { बिना, आपको सशर्त अभिव्यक्ति के अंत को सीमित करने का एक तरीका निर्दिष्ट करना होगा। आपको व्याकरण, पार्सर, gofmt, आदि को अपडेट करना होगा। यह भाषा की सतह को पूरी तरह से बदल देगा।

@ngrilly
संयम और भाषा को सरल रखना महत्वपूर्ण है।

आपके द्वारा उपयोग किए गए कुछ तर्क युक्ति में बहुत अधिक परिवर्तन को उचित ठहरा सकते हैं। यहां केवल सकारात्मक बिंदु नहीं हैं।

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

हाय @kroppt ,

भाषा को सरल रखना महत्वपूर्ण

मैं सहमत हूं और मुझे लगता है कि हम सभी इसके लिए प्रयास करते हैं।

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

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

आप सही हैं कि कल्पना में कुछ चीजें कुछ सिद्धांतों का उल्लंघन करती हैं जिन पर go की स्थापना की गई थी

पिछले कुछ वर्षों के दौरान, मैं गो टीम द्वारा प्रकाशित गो और उसके डिजाइन के बारे में लगभग सब कुछ पढ़ रहा हूं, और समझ में नहीं आता कि आपका क्या मतलब है। मुझे नहीं लगता कि try प्रस्ताव गो के मूलभूत सिद्धांतों का उल्लंघन करता है।

@ngrilly
https://talks.golang.org/2012/splash.article उन कुछ अवधारणाओं का वर्णन करता है जो go अलग बनाती हैं - स्पष्टता और सरलता, दूसरों के बीच में। मुझे लगता है कि इस नए बदलाव के साथ हममें से कुछ लोग इसी संघर्ष को देखते हैं। यह आसान है, लेकिन यह कम स्पष्ट है। मेरे लिए ऐसा लगता है कि सादगी में लाभ स्पष्टता के नुकसान से छोटा है। शायद मैं गलत हूँ और बस सतर्क हूँ।

@kroppt मैंने इस लेख को दर्जनों बार पढ़ा है ;-) मैं इस विचार से असहमत हूं कि कोशिश कोड को

@ngrilly
आप जो वर्णन कर रहे हैं वह मेरे "समर्थक" खंड में है:

• प्रोग्रामर अपने द्वारा किए जाने वाले कीस्ट्रोक्स की संख्या कम करते हैं।
• प्रोग्रामर्स के पास वर्तमान फ़ंक्शन ए ला मैक्रो से लौटने के लिए एक शॉर्टहैंड हो सकता है।
• nil चेक के समुद्र को देखने पर अब आंखें नहीं चमकतीं।

फिर से, जब हम इसे यहां सार्वभौमिक रूप से लागू नहीं कर रहे हैं, तो मुझे किसी सिद्धांत के सार्वभौमिक अनुप्रयोग का उल्लेख करने का कोई मतलब नहीं दिखता।

मैं इस विचार से असहमत हूं कि कोशिश कोड को खराब कर रही है

परिवर्तन का उद्देश्य कोड को अस्पष्ट/छिपाना/सरल बनाना/प्रतिनिधित्व करना है - अन्यथा हम मूल त्रुटि चेक ब्लॉक देखेंगे। सवाल यह है कि क्या यह अर्थ को कम स्पष्ट करता है।

मुझे लगता है कि go मूल रूप से सादगी का एक बड़ा संतुलन मारा, उस बिंदु तक जहां इसने स्पष्टता से दूर ले जाने के बजाय योगदान दिया। मैं यह नहीं बता सकता कि उन्होंने यह कैसे किया, लेकिन मेरी राय में try ऐसा नहीं है।

मुझे नहीं लगता कि हमें वर्बोसिटी को कोई समस्या माननी चाहिए। कोड को मनुष्यों द्वारा पढ़ने और समझने की आवश्यकता होती है - जिनका समय कंप्यूटर से अधिक महंगा होता है - और _समझना_ कठिन और समय लेने वाला हिस्सा होता है।

मुझे लगता है कि गो एरर हैंडलिंग की इंडेंटेशन संरचना मुझे यह जानने में मदद करती है कि क्या हो रहा है। प्रत्येक त्रुटि जांच स्पष्ट है। अधिकांश हैंडल न की गई त्रुटियां भी स्पष्ट हैं। यह मेरे लिए कोड को जल्दी समझने में मदद करता है।

मुझे यह भी लगता है कि जबकि if err != nil चेक थकाऊ लग सकते हैं, मुझे वास्तव में उन्हें _type_ की आवश्यकता नहीं है। मेरे पास बस मेरा संपादक है।

@kroppt

परिवर्तन का उद्देश्य कोड को अस्पष्ट/छिपाना/सरल बनाना/प्रतिनिधित्व करना है - अन्यथा हम मूल त्रुटि चेक ब्लॉक देखेंगे।

लेकिन आप किसी भी फ़ंक्शन कॉल के लिए इस तर्क का उपयोग कर सकते हैं! अगर मैं strings.HasPrefix("foobar", "foo") कॉल करता हूं, तो क्या यह कोड को अस्पष्ट करता है? क्या आप l := len("foo"); len("foobar") >= l && s[0:l] == "foo" लिखना और पढ़ना पसंद करेंगे?

@rossmcf

प्रत्येक त्रुटि जांच स्पष्ट है।

कोशिश अभी भी स्पष्ट रूप से त्रुटि की जाँच कर रहा है। यह कोशिश का राज है।

मुझे यह भी लगता है कि अगर गलती! = शून्य जांच कठिन लग सकती है, तो मुझे वास्तव में उन्हें टाइप करने की आवश्यकता नहीं है।

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

कोशिश अभी भी स्पष्ट रूप से त्रुटि की जाँच कर रहा है
try एब्स्ट्रैक्शन और स्ट्रिंग्स के बीच का अंतर। HasPrefix यह है कि try परोक्ष रूप से वापस आता है।
गो कोड पढ़ते समय, मुझे पता है कि निष्पादन प्रवाह मेरे फ़ंक्शन के भीतर तब तक बना रहता है जब तक कि मैं:

• रिटर्न प्रकार के बिना किसी फ़ंक्शन के समापन ब्रैकेट को पढ़ें
• कीवर्ड पढ़ें return , panic
• syscall.Exit(code) पढ़ें
  try , मैं उसी तरह कोड नहीं पढ़ सका। लाइनों पर दृष्टिगत रूप से स्कैन करना और शून्य "रिटर्न" स्टेटमेंट देखने का अर्थ अब "या तो ये सभी लाइनें निष्पादित होती हैं, या एक ब्लॉक, या प्रोग्राम समाप्त हो जाता है।"

@ngrilly आप FYI पोस्ट में एक से अधिक लोगों को उत्तर दे सकते हैं, एक दो घंटे में 10 उत्तर एक बिंदु पर लगातार 5 के साथ चर्चा का पालन करना मुश्किल बनाता है। कुछ भ्रांतियों से अलग आपकी पोस्ट पढ़ने के बाद मैंने कोशिश के लाभों का वर्णन करते हुए कोई नया ठोस तर्क नहीं देखा। मैंने एक ही लाभ देखा है: if err != nil की टाइपिंग को रोकना। यह संसाधनों को लीक करने के नए तरीकों को पेश करने की लागत पर आता है, कम संक्षिप्त कोड लिखने की क्षमता और सबसे खराब कोशिश करने की अनुमति देता है ।

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

एक एकल मूल्य वृद्धि के साथ औचित्य साबित करने के लिए यहां बहुत अधिक लागत है, मैं समर्थकों के उत्तरों में पुनर्जन्म देखता हूं: "मुझे अब if err != nil टाइप करने की आवश्यकता नहीं है" - वह चीज जो त्रुटियों के साथ उत्साहपूर्वक बचाव और अंतर्निहित है, वे हैं संपूर्ण गो समुदाय द्वारा मूल्य। हम if err != nil का उपयोग करते हुए लिखे गए एक दशक तक के कोड तक आ रहे हैं - जो कि कुछ सबसे उल्लेखनीय प्रौद्योगिकी प्रगति (docker, k8s, ...) एक ही समय में सभी बड़ी सफलता के साथ उपयोग करते हैं।

समापन में if err != nil एक बिल्टिन के साथ छिपाने का बोझ नहीं है, लेकिन कुछ ऐसा है जिसे हम सभी को भाषाओं की सफलता के लिए एक मुख्य घटक के रूप में पहचानना चाहिए। भले ही हम सामूहिक रूप से स्वीकार करें कि यह एक बोझ है, इसे हटाने के लिए बार उच्च और अडिग होना चाहिए। अभी कोशिश के बहुत से पहलू एक समझौता हैं।

मेरी राय है कि कौन सा तरीका आसान है लेकिन वे राय हैं। दिया गया प्रयास सरल है और वर्तमान स्पष्ट जाँच सरल है। महान दोनों तरीके सरल हैं। मेरे लिए समस्या यह है कि यह किसी दिए गए कोड के पाठक और लेखक दोनों के संज्ञानात्मक भार को बढ़ाता है। अब दोनों को चीजों को करने के कई तरीकों की व्याख्या करनी होगी। और लेखक को यह चुनना होता है कि किस तरह से काम करना है और/या बाकी पैकेज या प्रोजेक्ट की तुलना में चीजों को अलग तरीके से करने का जोखिम है जिस पर वे काम कर रहे हैं। अगर कोशिश स्पष्ट जांच की जगह ले रही थी जो अभी भी पार्स करने के लिए एक और चीज के रूप में निहित रिटर्न के कारण संज्ञानात्मक भार में वृद्धि करेगी।

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

इस तरह कुछ जोड़ने के लिए बार बहुत अधिक होना चाहिए, यह साबित करने के लिए लंबे समय तक प्रयोगात्मक होना चाहिए कि यह क्षेत्र से डेटा के साथ बेहतर है।

@cstockton

आप एक पोस्ट FYI में एक से अधिक लोगों को उत्तर दे सकते हैं, एक दो घंटे में 10 उत्तर एक बिंदु पर लगातार 5 के साथ चर्चा का पालन करना मुश्किल बनाता है।

इयान ने 7 दिन पहले इस चर्चा को गोलंग-नट्स में स्थानांतरित करने

@therealplato

कोशिश अमूर्त और स्ट्रिंग्स के बीच का अंतर है। हैसप्रिफ़िक्स यह है कि कोशिश परोक्ष रूप से वापस आती है।

यह सच है। किसी फ़ंक्शन को पढ़ते समय और "निकास" बिंदुओं की तलाश करते समय, हमें वापसी, घबराहट, लॉग की तलाश करनी होगी। पैनिक, ओएस। बाहर निकलें, लॉग। घातक, आदि ... और प्रयास करें। क्या ऐसी कोई समस्या है? किसी फ़ंक्शन में निकास बिंदुओं की संख्या वही रहेगी और फिर भी प्रयास के साथ या बिना स्पष्ट रूप से चिह्नित की जाएगी।

कीवर्ड पढ़ें वापसी, घबराहट

घबराहट कोई कीवर्ड नहीं है; यह एक अंतर्निहित कार्य है। अगर हम गो टीम के प्रस्ताव की आलोचना करने जा रहे हैं, जो शायद हम में से किसी की तुलना में भाषा डिजाइन के बारे में अधिक सक्षम है, तो कम से कम हमें चीजों को ठीक से परिभाषित करने का पक्ष लेना चाहिए। मैं

किसी फ़ंक्शन को पढ़ते समय और "निकास" बिंदुओं की तलाश करते समय, हमें वापसी, घबराहट, लॉग की तलाश करनी होगी। पैनिक, ओएस। बाहर निकलें, लॉग। घातक, आदि ... और प्रयास करें। क्या ऐसी कोई समस्या है?

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

@ngrilly

इयान ने 7 दिन पहले इस चर्चा को गोलंग-नट्स में स्थानांतरित करने का सुझाव दिया था, इस कारण से (किसी विशिष्ट टिप्पणी का जवाब देने का कोई तरीका नहीं, कोई थ्रेडिंग नहीं), सुझाव जिसे यह सुनिश्चित करने के लिए खारिज कर दिया गया था कि चर्चा "आधिकारिक" होगी। हमने जो मांगा है वह हमारे पास है।

संदेश शुरू करें

@ उपयोगकर्ता1
उत्तर 1

@ उपयोगकर्ता2
उत्तर 2

अंत संदेश

यही मतलब था।

@cstockton

मैंने एक ही लाभ देखा है: टाइपिंग को रोकना if err != nil.

try केवल if err != nil ही नहीं, बल्कि if err != nil { return ..., err } (3 पंक्तियों में स्वरूपित) के दोहराव वाले टाइपिंग और पढ़ने को रोकता है।

यह संसाधनों को लीक करने के नए तरीकों को पेश करने की कीमत पर आता है, कम संक्षिप्त कोड लिखने की क्षमता और सबसे खराब कोशिश करने की अनुमति देता है।

आपके द्वारा उल्लिखित संसाधन लीक के जोखिम को vet और lint से रोका जा सकता है।

"कम संक्षिप्त कोड" के बारे में, try का संपूर्ण बिंदु अधिक संक्षिप्त कोड लिखना है, इसलिए मैं आपके तर्क को नहीं समझता।

अत्यधिक फ़ंक्शन कॉल नेस्टिंग का जोखिम try लिए विशिष्ट नहीं है। किसी भी फ़ंक्शन कॉल को अत्यधिक नेस्टेड किया जा सकता है। कोड समीक्षा और लाइनिंग हमेशा की तरह मदद करेगी।

मुझे लगता है कि प्रस्तावकों द्वारा बनाई गई युक्ति और तर्क भ्रामक हैं, यह वर्तमान में सबसे खराब स्थिति वाले उदाहरणों को दिखाए बिना केवल सर्वोत्तम-मामले के उदाहरण प्रदान करता है।

शायद यह भावना आपसी है। हम सभी प्यारे गोफर हैं; आइए मूल्य निर्णय में न पड़ें ;-)

मुझे समर्थकों के जवाबों में उलटफेर दिखाई देता है: "मुझे अब टाइप करने की ज़रूरत नहीं है अगर गलती हुई है! = nil"

दोबारा, मुझे अब l := len("foo"); len("foobar") >= l && s[0:l] == "foo" टाइप करने की आवश्यकता नहीं है।
मैं इसके बजाय strings.HasPrefix("foobar", "foo") उपयोग कर सकता हूं।
यह try साथ इतना अलग कैसे है?
मैंने पहले पढ़ा था कि आप एक "प्रतिबंधित" try स्वीकार करेंगे जिसका नाम check होगा और यह नेस्टिंग को मना करेगा।

हमारे पास if err != nil का उपयोग करते हुए लिखे गए कोड के एक दशक तक आ रहे हैं - जो एक ही समय में कुछ सबसे उल्लेखनीय प्रौद्योगिकी प्रगति (docker, k8s, ...) का उपयोग सभी बड़ी सफलता के साथ करते हैं।

हमारे पास C, C++, Java, आदि में भी बहुत सारे बेहतरीन कोड लिखे हुए हैं। इस तर्क के साथ, हमारे पास Go नहीं होगा।

गो में त्रुटि प्रबंधन पर चर्चा पढ़ते समय, मुझे ऐसा नहीं लगा कि try प्रस्ताव के संबंध में हर कोई एक ही पृष्ठ पर था, इसलिए मैंने एक ब्लॉग पोस्ट लिखने का फैसला किया जो दर्शाता है कि try हो सकता है इस्तेमाल किया जा सकता है: https://faiface.github.io/post/how-to-use-try/

रेडिट पर संबद्ध चर्चा: https://www.reddit.com/r/golang/comments/c9eo3g/how_to_use_try_faiface_blog/

मुझे पता है कि यह मुद्दा try खिलाफ है, लेकिन मुझे उम्मीद है कि मेरी पोस्ट कुछ नए दृष्टिकोण ला सकती है :)

जाओ अटक गया है और सरल के विचार के लिए जादुई , या तार्किक के बीच संघर्ष कर रहा है।

पेशेवरों:

• बॉयलरप्लेट कम करें
• सरल
• अन्य भाषाओं के बीच मौजूदा पैटर्न
• ऐच्छिक

दोष:

• सीखने की अवस्था
• अंतर्निहित जादू
• नए प्रकार के कीड़े
• गो का विचार है, और if != nil साथ व्यावहारिक है लेकिन आप try उपयोग कर सकते हैं

मैं इस समुदाय esp की तरह महसूस करता हूँ। यहां गो सर्वे ^[1] में मतदान करने वाले लोगों के खिलाफ मतभेद है।
मतदाता इसे मुख्य चिंता के रूप में नहीं चुन सकते हैं बल्कि भविष्य के विचारों के लिए छोड़ सकते हैं।
लेकिन इसकी नियुक्ति के कारण इसका प्रभाव माना जाता था।

आईएमओ, भाषा सुविधा जोड़ना पुराना है और आधुनिक प्रोग्रामिंग तरीका संपादकों पर अधिक फीचर जोड़ रहा है यानी एम्मेट या भाषा स्निपेट, कोड फोल्डिंग और कलरिंग, रिफैक्टरिंग और फॉर्मेटिंग, डिबगिंग और टेस्टिंग, एक त्रुटि के समाधान का सुझाव देना और गोडोक या स्टैक ओवरफ्लो से उद्धृत करना , स्रोत कोड के शीर्ष पर UI, और स्रोत कोड को वर्बोज़ छोड़ दें
^{_{कोड if err != nil को try मोड़ें}}

@ngrilly

कोशिश दोहराए जाने वाले टाइपिंग और पढ़ने को रोकता है अगर गलती! = शून्य {वापसी ..., गलती} (3 पंक्तियों पर स्वरूपित), न सिर्फ अगर गलती! = शून्य।

क्या आप मुझ पर विश्वास करते हैं कि "यह आपको टाइप करने से रोकता है अगर गलती! = शून्य" का मतलब है कि मैं पूरी तरह से भूल गया था कि हम जो कोड टाइप करते हैं उसे भी पढ़ते हैं?

आपके द्वारा उल्लिखित संसाधन लीक के जोखिम को पशु चिकित्सक और लिंट से रोका जा सकता है।

मैंने एक चर्चा को जोड़ा कि मुझे क्यों लगता है कि पशु चिकित्सक और लिंट यहां एक उचित विकल्प नहीं है।

"कम संक्षिप्त कोड" के बारे में, कोशिश का पूरा बिंदु अधिक संक्षिप्त कोड लिखना है, इसलिए मैं आपके तर्क को नहीं समझता।

हां, क्या आपने लिंक पढ़ा था कि " कम संक्षिप्त कोड लिखने की क्षमता" वास्तव में आपकी ओर इशारा करती है, हो सकता है कि आप मेरे तर्क को समझ गए हों। _ध्यान दें, जिन लोगों के साथ आप चर्चा में भाग ले रहे हैं, उनके तर्कों को समझने के लिए थोड़ा समय लेना, उन्हें आपके विचार को स्वीकार करने में सक्षम जानकारी प्रस्तुत करने का पहला कदम है।_

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

दिलचस्प है, आइए वास्तव में इसे तोड़ दें:

1) अत्यधिक फ़ंक्शन कॉल नेस्टिंग का जोखिम प्रयास करने के लिए विशिष्ट नहीं है।

हां, यहां हर कोई समझता है कि फ़ंक्शन कैसे काम करता है।

2) किसी भी फ़ंक्शन कॉल को अत्यधिक नेस्टेड किया जा सकता है।

हां, यहां हर कोई समझता है कि फ़ंक्शन कैसे काम करता है।

3) कोड समीक्षा और लाइनिंग हमेशा की तरह मदद करेगी।

हां, आपने लिंट तर्क पहले ही बना दिया है और "कोड समीक्षा तर्क" एक और बाहरी भाषा नियंत्रण है जो मैंने आपसे लिंक की गई पोस्ट में बनाया था।

शायद यह भावना आपसी है। हम सभी प्यारे गोफर हैं; आइए मूल्य निर्णय में न पड़ें ;-)

मुझे समझ नहीं आ रहा है? प्रस्ताव में कार्यान्वयन द्वारा प्रदान की जाने वाली पूर्ण क्षमता का कोई उदाहरण नहीं है, केवल इच्छित उपयोग है। प्रस्ताव के प्रभावों को मापने में मदद करने के लिए उपयोग किया जाने वाला tryhard टूल सबसे सीमित और उचित रूप में try का उपयोग करता है, यह एक साधारण तथ्य है।

फिर से, मुझे अब टाइप करने की आवश्यकता नहीं है l := len("foo"); लेन("foobar")>= l && s[0:l] == "foo"।
मैं इसके बजाय string.HasPrefix("foobar", "foo") का उपयोग कर सकता हूं।
कोशिश के साथ यह इतना अलग कैसे है?

मैं प्रत्येक विरोधी दृष्टिकोण से एक स्थिति निकालने की पूरी कोशिश करता हूं, अन्यथा मैं इसे खत्म करने का तर्क नहीं दे सकता। मैं वास्तव में इसे यहाँ नहीं देख सकता, मुझे क्षमा करें। मैं इसकी व्याख्या करने जा रहा हूं जिस तरह से मैं इसे समझ सकता हूं: शाब्दिक रूप से।

यह ( strings.HasPrefix ) try साथ इतना अलग कैसे है?

स्ट्रिंग्स।हैसप्रीफिक्स

func HasPrefix

func HasPrefix(s, उपसर्ग स्ट्रिंग) बूल

HasPrefix परीक्षण करता है कि क्या स्ट्रिंग s उपसर्ग से शुरू होती है।

प्रयत्न

func try एक नया फंक्शन जैसा बिल्ट-इन है जिसे सिग्नेचर के साथ ट्राई कहा जाता है (छद्म कोड)

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

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

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

फ़ंक्शन कॉल f () के रूप में (छद्म कोड) के साथ प्रयास करें

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

turns into the following (in-lined) code:

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te     // assign te to the error result parameter
        return       // return from enclosing function
}
x1, … xn = t1, … tn  // assignment only if there was no error

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

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

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

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

a, b = try(f())

त्रुटि की स्थिति में a और b अपरिवर्तित रहेंगे। हालांकि यह एक सूक्ष्म अंतर है, हमारा मानना ​​है कि इस तरह के मामले दुर्लभ हैं। यदि वर्तमान व्यवहार अपेक्षित है, तो if कथन रखें।

वे इस मायने में भिन्न हैं कि try के विवरण में पाया गया संपूर्ण पाठ string.HasPrefix में मौजूद नहीं है। एक बेहतर सवाल यह होगा कि समान कैसे हैं, जिसके लिए मैं उत्तर दूंगा कि वे दोनों कॉल के कुछ पहलुओं को साझा करते हैं और कुछ नहीं।

मैंने पहले पढ़ा था कि आप एक "प्रतिबंधित" प्रयास को स्वीकार करेंगे जिसे चेक नाम दिया जाएगा और घोंसले के शिकार को मना करेगा।

खुशी है कि आपने कोशिश के खिलाफ मेरा केंद्रीय तर्क पढ़ा: कार्यान्वयन पर्याप्त प्रतिबंधात्मक नहीं है। मेरा मानना ​​है कि या तो कार्यान्वयन उन सभी प्रस्तावों के उपयोग के उदाहरणों से मेल खाना चाहिए जो संक्षिप्त और पढ़ने में आसान हैं।

_Or_ प्रस्ताव में ऐसे उदाहरण होने चाहिए जो कार्यान्वयन से मेल खाते हों ताकि इस पर विचार करने वाले सभी लोगों को गो कोड में अनिवार्य रूप से दिखाई देने वाली चीज़ों से अवगत कराया जा सके। सभी कोने के मामलों के साथ-साथ आदर्श लिखित सॉफ़्टवेयर से कम समस्या निवारण का सामना करना पड़ सकता है, जो किसी भी भाषा/वातावरण में होता है। इसे ऐसे सवालों का जवाब देना चाहिए जैसे कई नेस्टिंग स्तरों के साथ स्टैक ट्रेस कैसा दिखेगा, क्या त्रुटियों के स्थान आसानी से पहचाने जा सकते हैं? विधि मानों, अनाम फ़ंक्शन शाब्दिकों के बारे में क्या? यदि fn() को कॉल करने वाली लाइन विफल हो जाती है, तो नीचे दिए गए स्टैक ट्रेस किस प्रकार का उत्पादन करते हैं?

fn := func(n int) (int, error) { ... }
return try(func() (int, error) { 
    mu.Lock()
    defer mu.Unlock()
    return try(try(fn(111111)) + try(fn(101010)) + try(func() (int, error) {
       // yea...
    })(2))
}(try(fn(1)))

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

गो अन्य डेवलपर्स के लिए कम से कम संभव तरीके प्रदान करता है और मैं एक-दूसरे का समय बर्बाद करने के लिए हमें समान सांसारिक निर्माणों का उपयोग करने तक सीमित करता हूं। मैं भारी लाभ के बिना इसे खोना नहीं चाहता। मुझे विश्वास नहीं है "क्योंकि कोशिश को एक समारोह के रूप में लागू किया जाता है" एक भारी लाभ होने के लिए। क्या आप कोई कारण बता सकते हैं कि ऐसा क्यों है?

इस त्रुटि से निपटने के मुद्दे पर समय बर्बाद न करें, हमें जेनरिक दें और हम रस्ट के परिणाम जैसा कुछ बनाएंगे।

जाओ अटक गया है और सरल के विचार के लिए जादुई , या तार्किक के बीच संघर्ष कर रहा है।

पेशेवरों:

• बॉयलरप्लेट कम करें
• सरल
• अन्य भाषाओं के बीच मौजूदा पैटर्न
• ऐच्छिक

दोष:

• सीखने की अवस्था
• अंतर्निहित जादू
• नए प्रकार के कीड़े
• गो का विचार है, और if != nil साथ व्यावहारिक है लेकिन आप try उपयोग कर सकते हैं

मैं इस समुदाय esp की तरह महसूस करता हूँ। यहां गो सर्वे [1] में मतदान करने वाले लोगों के खिलाफ मतभेद है।
मतदाता इसे मुख्य चिंता के रूप में नहीं चुन सकते हैं बल्कि भविष्य के विचारों के लिए छोड़ सकते हैं।
लेकिन इसकी नियुक्ति के कारण इसका प्रभाव माना जाता था।

आईएमओ, भाषा सुविधा जोड़ना पुराना है और आधुनिक प्रोग्रामिंग तरीका संपादकों पर अधिक फीचर जोड़ रहा है यानी एम्मेट या भाषा स्निपेट, कोड फोल्डिंग और कलरिंग, रिफैक्टरिंग और फॉर्मेटिंग, डिबगिंग और टेस्टिंग, एक त्रुटि के समाधान का सुझाव देना और गोडोक या स्टैक ओवरफ्लो से उद्धृत करना , स्रोत कोड के शीर्ष पर UI, और स्रोत कोड को वर्बोज़ छोड़ दें
कोड if err != nil को try मोड़ें

मैं वह था जिसने त्रुटि को संसाधित करने की संभावना के बिना कठोर त्रुटि प्रबंधन के लिए मतदान किया था। कोशिश के लिए नहीं।

रस्ट के Result प्रकार जैसी किसी भी चीज़ को दूर से रीमेक करने के लिए हमें जेनरिक की तुलना में बहुत अधिक की आवश्यकता होगी। यहां तक ​​​​कि _if_ Result प्रकार पूरी तरह से जेनरिक के साथ बनाया जा सकता है, शुरुआती प्रोग्रामर को किसी त्रुटि को ठीक से संभालने से पहले जेनरिक को जानना होगा, या किसी फ़ंक्शन से एक त्रुटि वापस करना होगा " Result रास्ता "

@deanveloper , मेरी बात यह है: मेरे पास "वाक्यविन्यास परिवर्तन" की तुलना में जेनरिक से बहुत अधिक लाभ है और मेरा मानना ​​​​है कि यह समुदाय के लिए भी सच है।

@txgruppi मैं सहमत हो सकता हूं कि जेनरिक की उच्च प्राथमिकता होनी चाहिए। मैं सिर्फ यह कहने की कोशिश कर रहा था कि मुझे नहीं लगता कि जेनरिक त्रुटि प्रबंधन के लिए एक अच्छा विकल्प होगा।

@deanveloper , मेरी राय में यह त्रुटि प्रबंधन समस्या सिर्फ सौंदर्य प्रसाधन है, लोग कुछ समय स्थिर होने पर चर्चा करने में समय व्यतीत कर रहे हैं और अच्छी तरह से काम करते हैं क्योंकि आप कुछ अतिरिक्त कोड टाइप करना चाहते हैं। बस बेहतर कोड लिखना सीखें और इसे डिज़ाइन परिवर्तनों के साथ हल करें।
किसी के कहने से पहले जेनरिक बेहतर कोड के साथ ठीक करना आसान है: समय त्रुटियों को संकलित करें ...

क्या इसे स्निपेट या कीबोर्ड मैक्रो से हल किया जा सकता है? तब यह कोई मुद्दा नहीं है।

@txgruppi

बस बेहतर कोड लिखना सीखें और इसे डिज़ाइन परिवर्तनों के साथ हल करें।

मानक पुस्तकालय में सभी त्रुटि-प्रबंधन कोड का 70% वर्तमान में try के लिए उपयुक्त है क्योंकि रॉबर्ट ग्रिसेमर ने अपने tryhard टूल का उपयोग करते हुए पाया । अधिक कोड में परिवर्तन के लिए पात्र होंगे, जैसे (अभी तक मौजूद नहीं) fmt.HandleErrorf फ़ंक्शन का उपयोग करना। मुझे आशा है कि आप मानक पुस्तकालय को खराब कोड नहीं कहना चाहेंगे।

क्या इसे स्निपेट या कीबोर्ड मैक्रो से हल किया जा सकता है? तब यह कोई मुद्दा नहीं है।

यह कोड पढ़ने के बारे में भी है। इसलिए हमें thing.Thing thing = new thing.Thing(thing.THING);

@faiface , गुणवत्ता सॉफ़्टवेयर विकसित करने के रास्ते में 'अगर गलती! = शून्य' हो रही है? मुझे ऐसा नहीं लगता।
क्या जेनरिक की कमी गुणवत्तापूर्ण सॉफ्टवेयर विकसित करने के रास्ते में आ रही है? हाँ यही है।

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

@faiface मानक पुस्तकालय वास्तविक गो कोड का अच्छा प्रतिनिधित्व नहीं है। ऐसा इसलिए है क्योंकि मानक पुस्तकालय के लिए संदर्भ जोड़ने के बिना केवल पास-अप त्रुटियों की अधिक संभावना है, उदाहरण के लिए io/ioutil वास्तव में त्रुटियों को सजाने की आवश्यकता नहीं है, यह केवल io में हुई त्रुटि को पारित कर सकता है

@deanveloper @faiface जब गो कॉर्पस के विरुद्ध चलता है:

--- stats ---
 401679 (100.0% of  401679) func declarations
  97496 ( 24.3% of  401679) func declarations returning an error
 991348 (100.0% of  991348) statements
 217490 ( 21.9% of  991348) if statements
  88891 ( 40.9% of  217490) if <err> != nil statements
    485 (  0.5% of   88891) <err> name is different from "err" (-l flag lists details)
  59500 ( 66.9% of   88891) return ..., <err> blocks in if <err> != nil statements
  29391 ( 33.1% of   88891) complex error handler in if <err> != nil statements; cannot use try (-l flag lists details)
    596 (  0.7% of   88891) non-empty else blocks in if <err> != nil statements; cannot use try (-l flag lists details)
  52810 ( 59.4% of   88891) try candidates (-l flag lists details)

तो, वास्तविक जीवन कोड में, त्रुटि-जांच के लिए 40% if-statement लिखे गए हैं, और try उनमें से 59% को बॉक्स से बाहर कर सकते हैं।

मैं सहमत हूं। मैं ठीक हूँ अगर गलती! = शून्य। यह उन कार्यों के लिए सरल और साफ है जो एकल त्रुटि मान लौटाते हैं। जब त्रुटि का संदर्भ मायने रखता है तो मैं त्रुटि पैकेज और उसके कारण/लपेटने के कार्यों का भी शौकीन हूं। कोड प्रॉपर्टी के साथ कस्टम त्रुटियों का उपयोग करना (जहां तक ​​​​मुझे पता है) के लिए आपको या तो एक प्रकार का दावा करना होगा या मानक त्रुटि इंटरफ़ेस के स्थान पर पूरी तरह से कुछ उपयोग करना होगा। किसी भी तरह से, मैंने खुद को कभी भी गो कोड को पढ़ना या लिखना नहीं पाया है और वर्तमान में त्रुटि प्रबंधन कैसे काम करता है, इस बारे में किसी प्रकार की परेशानी महसूस कर रहा हूं। मैंने जिन परेशानियों का सामना किया है, वे ऐसे मामले हैं जहां वस्तुओं के संग्रह को संसाधित करने के परिणामस्वरूप कई त्रुटियां हो सकती हैं। हालाँकि, यह डिज़ाइन की समस्या है और भाषा की समस्या नहीं है।

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

7/5/19 को, निकोलस ग्रिली नोटिफिकेशन @github.com ने लिखा:

@kroppt मैंने दर्जनों बार पढ़ा है ;-) मैं इस विचार से असहमत हूं कि try is
कोड को भ्रमित करना। कोशिश सिर्फ एक अंतर्निहित फ़ंक्शन है जिसका उपयोग कुछ कारक करने के लिए किया जाता है
दोहराव कोड। हम प्रोग्रामर के रूप में हर समय ऐसा करते हैं। जब हम पहचानते हैं a
दोहराव पैटर्न, हम इसे एक नए फ़ंक्शन में फैक्टर करते हैं। अगर हमने नहीं किया, तो हम
इसमें एक लंबा मुख्य () फ़ंक्शन होगा जिसमें हमारे सभी कोड इनलाइन होंगे।

मैं आपको कपटी कहने के लिए ललचाता हूं, लेकिन मैं इयान लांस टेलर का सम्मान करता हूं
चर्चा को विनम्र रखने के अलौकिक प्रयास और मैं वास्तव में नहीं कर सकता
देखें कि इस फोरम में जानबूझकर झूठ बोलने से किसी को क्या हासिल होगा।

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

ज्वलंत हुप्स को कभी भी ध्यान न दें कि "डिफर" का उपयोग करने से निपटने के लिए परिचय होता है
"कोशिश - छद्म कार्य" के अधिक रहस्यमय उपयोगों के साथ। कोई
कहीं और कहा, मोटे तौर पर "मैं कोड में try पार नहीं आना चाहता
मैंने पढ़ा।'' मुझे भी ऐसा ही लगता है और इसे के नीचे नहीं बहना चाहिए
कालीन

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

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

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

बिंदु को स्पष्ट करने के लिए, एक पाठक से वापसी मूल्यों पर विचार करें:
io.EOF एक विशेष मामला है जो कभी सफल होता है तो कभी a
विफलता, लेकिन गो मानकों द्वारा गर्व से एक त्रुटि है ("io.Err!= nil")।
क्या हम इसे भी संक्षिप्त करने का कोई तरीका निकालने जा रहे हैं? लगभग निश्चित रूप से
नहीं, क्योंकि हम इसकी "गलतता" को "क्षमा" करने के लिए काफी अभ्यस्त हैं।

मैंने लंबे समय से एक समान "स्थिति" या . को व्यक्त करने के लिए लूप से बाहर निकलने की प्रतीक्षा की है
कंडीशन कोड (खोज एक पाए गए मान या विफलता के साथ समाप्त हो सकती है, कैसे
क्या आप बता सकते हैं, यदि आप अलग-अलग चीजें करना चाहते हैं? आप एक परीक्षण जोड़ें,
जहां ज्ञान पहले से मौजूद है - एक ही मुद्दा, अलग
संदर्भ)।

ये पारंपरिक भाषाओं में वास्तविक संवर्द्धन हैं: बॉयलर को कम करना
प्लेट बेतुका है, तुलना करके।

और, टर्नरी ऑपरेटर के साथ तुलना समान रूप से मान्य है: यदि ?:
अनुमति नहीं है "ऐसा न हो कि इसका दुरुपयोग किया जाए", तो कोशिश की अनुमति नहीं दी जानी चाहिए,
या तो, कम से कम उन आधारों पर।

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

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

त्रुटि प्रबंधन के भीतर "स्थगित" निर्माण (जिसे मैंने अपनाया है -
इसके आयात को कहीं और महसूस किए बिना - लगातार अंतिम रूप देने में
SQL लेनदेन: tx.Rollback/tx.Commit) मेरे लिए एक रहस्योद्घाटन रहा है।
और भी सिद्धांत हो सकते हैं जिन्हें "के दायरे में" सीखा जा सकता है
गो पहले से क्या प्रदान करता है: आइए अभी के लिए उस बॉक्स के भीतर रहें।

एक ऐसी चीज, जो बंद हो, एक त्रुटि रिपोर्टिंग को पास करना होगा
पारंपरिक के तहत निष्पादित होने वाली "त्रुटि। विधियों" की एक सूची कार्य करें
स्थितियाँ (io.EOF, sql.ErrNoRows), परिणाम की रिपोर्ट करने के बजाय
काले और सफेद के रूप में। लेकिन मैं ऐसे मामलों में अशिक्षित हूँ, मेरे सुझाव
बहुत भोले हैं, दूसरों को (रोजर, क्या आप सुन रहे हैं?) समान पोषण करते हैं
विचारों को साकार करना।

लुसियो।

"यह टाइप करने के लिए कठिन नहीं है। यह पढ़ने के लिए कठिन है, जब हमारे पास समान होता है
हर जगह 3 लाइनें। यह एक दोहराव है, और हम आमतौर पर प्रोग्रामर के रूप में
इन्हें बाहर निकालने की प्रवृत्ति रखते हैं। हो सकता है कि कोशिश में अन्य कमियां हों, लेकिन यह नहीं
एक मुझे लगता है।"

फिर से, कपटी या कम से कम, युक्तिसंगत। मैं अनुदान देता हूं कि वे
तीन पंक्तियाँ जितनी बार लिखी जाती हैं उससे कहीं अधिक बार पढ़ी जाती हैं, लेकिन
दर्द को कम करने के उद्देश्य से ग्रिसेमर लिखने में है पढ़ने में नहीं

• जिसे वह निस्संदेह एक लाभकारी परिणाम के रूप में मानता है।

लेकिन "गलती! = शून्य" एक बहुत ही परिचित मार्कर है और जब "पढ़ना" - as
एक संपादक का उपयोग करके "खोज" के विपरीत, वह पैटर्न दोनों के लिए आसान है
स्पॉट और रद्द करने में आसान। इसे फ़ैक्टर करना उसी में नहीं है
लीग बिल्कुल। और कीमत गलत है।

"हम प्रोग्रामर के रूप में" पहले अधिक जटिल पैटर्न को कारक बनाते हैं,
भले ही वे शायद ही कभी होते हैं। हम यह भी जानते हैं कि "अगर गलती!= शून्य {वापसी
err }" को निर्देशों के एक बहुत ही सरल अनुक्रम में संकलित किया गया है, if
कोई नहीं करता, उन्हें यहाँ हाथ उठाने दो। क्या कोई समान हो सकता है
विश्वास है कि यह "कोशिश - समारोह" के साथ होगा?

लुसियो।

@lootch अरे यार, लोगों को कपटी कहना वास्तव में अनुत्पादक है, मुझे पूरा यकीन है कि वे आपके द्वारा चिह्नित किए गए बयानों के रूप में बहुत उचित नहीं हैं।

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

बहुत सारे दोहराव वाले कोड पढ़ने को धीमा कर देते हैं, इसलिए मैं यह नहीं देखता कि यह कैसे कपटी है।

इनके प्रति आपके प्रतिवाद मूल रूप से "आओ यार, यह इतनी बड़ी बात नहीं है"। खैर, कई लोगों के लिए यह है।

कौन चाहता है कि गलत लोग हमारे समुदाय में शामिल हों?

यह सुपर अहंकारी गेट कीपिंग है। साथ ही, tryhard टूल ने खुलासा किया है कि try आज के अधिकांश गो कोडबेस में सीधे लागू होता है। इसे सीधे मानक पुस्तकालय में 70% त्रुटि प्रबंधन कोड पर लागू किया जा सकता है। कोड में परिवर्तन के साथ ( defer आदि का उपयोग करके त्रुटि सजावट का उपयोग करने के लिए), मेरा मानना ​​​​है कि यह सभी गो कोड में 80% से अधिक त्रुटि प्रबंधन पर लागू होगा।

सहमत हूं, मैं यहां निशान से आगे निकल रहा हूं। मैं माफी माँगता हूँ।

मुझे लगता है कि हम में से कुछ इस चर्चा के रूप में कॉलर के नीचे गर्म हो रहे हैं
हलकों में घूम रहा है।

7/7/19 पर, मीकल स्ट्रबा [email protected] लिखा है:

@lootch अरे यार, लोगों को कपटी कहना वास्तव में अनुत्पादक है, मैं
पूरा यकीन है कि वे आपके द्वारा चिह्नित किए गए बयानों के रूप में सुंदर नहीं हैं
यथोचित।

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

बहुत सारे दोहराव वाले कोड पढ़ने को धीमा कर देते हैं, इसलिए मुझे नहीं पता कि यह कैसा है
कपटी या तो।

इनके प्रति आपका प्रतिवाद मूल रूप से है "आओ यार, यह ऐसा नहीं है"
बड़ी बात"। ठीक है, कई लोगों के लिए यह है।

कौन चाहता है कि गलत लोग हमारे समुदाय में शामिल हों?

यह सुपर अहंकारी गेट कीपिंग है। साथ ही, tryhard टूल से पता चला है कि
try आज के अधिकांश गो कोडबेस में सीधे लागू होता है। यह हो सकता है
सीधे मानक पुस्तकालय में 70% त्रुटि प्रबंधन कोड पर लागू होता है। साथ में
कोड में परिवर्तन ( defer , आदि का उपयोग करके त्रुटि सजावट का उपयोग करने के लिए), मुझे विश्वास है
यह सभी गो कोड में 80% से अधिक त्रुटि प्रबंधन पर लागू होगा।

--
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/golang/go/issues/32825#issuecomment -508971768

--
लुसियो डी रे
2 पीट रिट्रीफ St
केस्टेल (पूर्वी मुक्त राज्य)
9860 दक्षिण अफ्रीका

दूरभाष: +27 58 653 1433
सेल: +27 83 251 5824
फैक्स: +27 58 653 1435

@lootch आत्म-जागरूक होने पर सहारा देता है! मैं चर्चा को मंडलियों में जाते हुए देखने की हताशा को समझ सकता हूँ.

मैं भी इसे इसी तरह देखता हूं और मैं दूसरी तरफ हूं।

शायद दोनों पक्ष एक दूसरे को समझने में ही असफल हो रहे हैं। क्या आपने मेरा ब्लॉग पोस्ट पढ़ा है जिसका नाम है 'कोशिश' का उपयोग कैसे करें? जहां मैं यह दिखाने का प्रयास करता हूं कि व्यवहार में 'कोशिश' का उपयोग करना कैसा दिखेगा, निष्पक्ष रहने के लिए अपनी पूरी कोशिश कर रहा हूं?

7/7/19 पर, मीकल स्ट्रबा [email protected] लिखा है:

[...]
शायद दोनों पक्ष दूसरे पक्ष को समझने में ही असफल हो रहे हैं। क्या तुम
हाउ टू यूज़ नामक मेरा ब्लॉग पोस्ट पढ़ें 'प्रयत्न'? जहाँ मैं करने का प्रयास करता हूँ
दिखाएँ कि 'कोशिश' का उपयोग करना व्यवहार में कैसा दिखेगा, रहने के लिए अपनी पूरी कोशिश कर रहा हूँ
निष्पक्ष?

मैं कबूल करता हूं कि मैंने नहीं किया, मैं जोश से चाहता हूं कि मुझे कभी :-)

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

यदि नहीं, तो कृपया मुझे ठेस पहुँचाएँ, अच्छी पठन सामग्री का एक विशेष स्थान है
मेरे जीवन में :-)

लुसियो।

@lootch मैंने कम से कम कोड में 'कोशिश' के कई पहलुओं को दिखाने के लिए अपनी पूरी कोशिश की (यानी जब यह लागू होता है और जब यह नहीं होता है) और इसे यथासंभव निष्पक्ष और यथार्थवादी बना देता हूं। लेकिन निश्चित रूप से, इसके लिए मेरा शब्द न लें :)

संबंधित Reddit चर्चा पर यह सबसे ऊपर की टिप्पणी थी:

यह एक उपयोगी निष्पक्ष काल्पनिक उदाहरण है। बातचीत में कुछ रचनात्मक जोड़ने के लिए धन्यवाद जो सिर्फ "यह बेकार" नहीं है।

@lootch मैंने कम से कम कोड में 'कोशिश' के कई पहलुओं को दिखाने के लिए अपनी पूरी कोशिश की (यानी जब यह लागू होता है और जब यह नहीं होता है) और इसे यथासंभव निष्पक्ष और यथार्थवादी बना देता हूं। लेकिन निश्चित रूप से, इसके लिए मेरा शब्द न लें :)

संबंधित Reddit चर्चा पर यह सबसे ऊपर की टिप्पणी थी:

यह एक उपयोगी निष्पक्ष काल्पनिक उदाहरण है। बातचीत में कुछ रचनात्मक जोड़ने के लिए धन्यवाद जो सिर्फ "यह बेकार" नहीं है।

एक तर्क के रूप में फ़ाइल पथ के साथ कार्य? यह अकेले एक कारण होगा कि यह कोड मेरी समीक्षा को पारित नहीं करेगा। क्या होगा अगर कुछ फ़ील्ड गायब हैं? पुन: व्यवस्थित?

@sirkon बहुत लंबा नहीं होने के प्रयोजनों के लिए, उदाहरण को सरल बनाया गया है। आपके द्वारा उठाई गई समस्याओं को ठीक करने के लिए जिन परिवर्तनों की आवश्यकता होगी, वे त्रुटि प्रबंधन प्रथाओं को प्रभावित नहीं करते हैं, हालांकि, जो कि वहां मायने रखता है।

आपके द्वारा उठाई गई समस्याओं को ठीक करने के लिए आवश्यक परिवर्तन त्रुटि प्रबंधन प्रथाओं को प्रभावित नहीं करते हैं

क्योंकि तुमने ऐसा कहा?

1. अपने ब्लॉग के शीर्षक से शुरू करें: इसे "कैसे नहीं लिखना" कहा जाना चाहिए, क्योंकि, मैं दोहराता हूं, पैरामीटर के रूप में फ़ाइल पथ का उपयोग करना वास्तव में एक बुरा अभ्यास है और, स्पष्ट रूप से, नीचे एक संपूर्ण कोड भी है।
2. क्या आपको इसका एहसास है?
   go resp := Respondent{ Name: name, Gender: try(parseField(s, &line, "gender")), OS: try(parseField(s, &line, "os")), Lang: try(parseField(s, &line, "lang")), }
   खराब त्रुटि संदेश उत्पन्न करेगा? कम से कम अनपेक्षित फ़ील्ड त्रुटि संदेश और अनुपलब्ध फ़ील्ड त्रुटि संदेश होना चाहिए। आपकी स्क्रिप्ट का निदान घटिया है।

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

@ सिर्कोन चलो,

क्या आपको एहसास है कि यह खराब त्रुटि संदेश उत्पन्न करेगा?

वे मॉडल के लिए पूरी तरह से पर्याप्त हैं। प्रारूप में सभी फ़ील्ड और क्रम में होने की उम्मीद है। त्रुटि संदेश इसे बहुत स्पष्ट रूप से बताता है।

यदि आप कोड की गुणवत्ता का विरोध करना चाहते हैं, तो आप इसे अपने गुणवत्ता मानकों के अनुसार क्यों नहीं लिखते? यदि आप ऐसा करते हैं, तो मैं try का उपयोग करने के लिए आपके कोड को फिर से लिखने की पूरी कोशिश करूंगा।

पीएस ने आपके रेपो पर एक नजर डाली। क्या आपको एहसास है कि गो आपके कार्यों के लिए एक खराब उपकरण है?

क्या आप मेरे कार्यों के लिए दूसरा सुझाव देते हैं? मैंने काफी कुछ इस्तेमाल किया है। बीटीडब्ल्यू, यह काफी ऑफ-विषय है।

@faiface

क्या आप मेरे कार्यों के लिए दूसरा सुझाव देते हैं? मैंने काफी कुछ इस्तेमाल किया है। बीटीडब्ल्यू, यह काफी ऑफ-विषय है।

जंग? सी++?

@sirkon

जंग? सी++?

हम वहाँ चलें। मैंने गो के साथ समझौता करने से पहले दोनों का उपयोग किया है। मैंने कभी पीछे मुड़कर नहीं देखा।

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

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

@deanveloper टिप्पणी के लिए धन्यवाद!

बीटीडब्ल्यू

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

यदि आप मेरे ब्लॉग का जिक्र कर रहे हैं, तो वास्तव में बहुत सारी त्रुटि सजावट चल रही है, ठीक उसी तरह नहीं जैसे @sirkon करेगा। यहां प्रोग्राम से कुछ त्रुटि संदेश दिए गए हैं जो try :

parse respondnts.txt: open respondnts.txt: no such file or directory
parse respondents.txt: line 12: parse field gender: expected "gender:"
parse respondents.txt: line 9: expected empty line
parse respondents.txt: line 4: parse field lang: EOF

@faiface मेरी गलती, मुझे और विशिष्ट होना चाहिए था। जब आप एक ही फ़ंक्शन में एकाधिक त्रुटि संदेश चाहते हैं, तो try त्रुटि सजावट को हतोत्साहित करता है। check/handle मसौदे के साथ और "नामित हैंडलर" काउंटरप्रपोजल के साथ ऐसा करना संभव था। प्रत्येक संदेश के चारों ओर सजावट जोड़ने में सक्षम होने के लिए निर्दिष्ट विशिष्ट उदाहरण में यह बहुत उपयोगी होता (जहां आप try का उपयोग कर रहे थे) प्रत्येक संदेश के चारों ओर सजावट जोड़ने में सक्षम होने के लिए, लेकिन दुर्भाग्य से प्रयास प्रस्ताव इसे करना थोड़ा कठिन बनाता है अपना स्वयं का कार्य लिखे बिना।

हालांकि आपके विशिष्ट मामले में चेक/हैंडल ने उतनी मदद नहीं की होगी। लेकिन प्रस्तावित विचार catch और करने के लिए अन्य counterproposals try ऐड अतिरिक्त सजावट के रूप में के रूप में त्रुटियों को संभालने में सक्षम हो गया होता।

@deanveloper ठीक है, अधिकांश समय आपको किसी फ़ंक्शन के भीतर सभी त्रुटियों के लिए समान सजावट का उपयोग करने की आवश्यकता होती है क्योंकि उप-फ़ंक्शंस से अपना संदर्भ प्रदान करने की अपेक्षा की जानी चाहिए। हालाँकि, जब आपको एक ही फंक्शन में चीजों को अलग तरह से सजाना होता है, तब भी कोशिश के साथ एक आसान उपाय होता है:

..., err := functionThatCanFail(...)
try(errors.Wrapf(err, ...))

या बस बड़े फ़ंक्शन को कई छोटे में विभाजित करें।

@faiface मेरी नज़र में उस समय किसी को केवल if err != nil उपयोग करना चाहिए, लेकिन मुझे लगता है कि यह वरीयता का मामला है।

हालांकि कभी-कभी (जैसे संरचना-प्रारंभिक मामले में) कई कार्यों में विभाजित करना एक अच्छा विचार नहीं है। हालांकि मुझे लगता है कि मैं थोड़ा नाइटपिकी हो रहा हूं।

मैं वास्तव में try खिलाफ सुपर नहीं हूं, लेकिन मैं वास्तव में एक बड़ा समर्थक भी नहीं हूं। मुझे लगता है कि वहाँ एक और बेहतर समाधान है।

@deanveloper

हालांकि कभी-कभी (जैसे संरचना-प्रारंभिक मामले में) कई कार्यों में विभाजित करना एक अच्छा विचार नहीं है।

सच है, लेकिन उन्हें अलग तरह से सजाने की भी जरूरत नहीं है, क्योंकि सभी आवश्यक विशिष्ट सजावट parseField से आती है।

मुझे लगता है कि वहाँ एक और बेहतर समाधान है।

यह बिलकुल संभव है! अगर मुझे एक बेहतर समाधान दिखाई देता है, तो मैं एक मिनट में try छोड़ दूंगा :)

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

@faiface मैं इस कथन से पूरी तरह असहमत हूं। प्रत्येक फ़ंक्शन कॉल स्टैक पर किसी अन्य का उप-फ़ंक्शन है। इसका मतलब है कि त्रुटि प्रबंधन प्रवाह में इसकी समान जिम्मेदारियां हैं (जो ऊपरी दायरे में त्रुटि संदर्भ प्रदान करती है)।

एक फ़ंक्शन की कल्पना करें जो डेटा के दो हिस्सों को एक फ़ाइल में जोड़ता है। यदि आप मुश्किल से 'फाइल में नहीं लिख सके' स्टेटमेंट लौटाते हैं, तो आप कैसे भेद करेंगे कि उनमें से कौन सा एपेंड विफल हो गया है?

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

@mklimuk मेरी टिप्पणी का एक महत्वपूर्ण हिस्सा "ज्यादातर समय" है। आपके द्वारा प्रदान किया गया उदाहरण शायद if err != nil द्वारा सबसे अच्छा संभाला जाता है। जैसा कि कई बार उल्लेख किया गया है, try को सभी स्थितियों को संभालने के लिए डिज़ाइन नहीं किया गया है, केवल सबसे आम हैं।

और सबूत से पता चलता है कि यह ऐसा करता है, क्योंकि मानक पुस्तकालय में सभी त्रुटि प्रबंधन कोड का 70% try आउट-ऑफ-द-बॉक्स का उपयोग कर सकता है और यह सभी त्रुटि प्रबंधन कोड के 59% के लिए जाता है जंगली।

@faiface अच्छी तरह से तथ्य यह है कि try स्पष्ट त्रुटि प्रबंधन को प्रतिस्थापित कर सकता है इसका मतलब यह नहीं होना चाहिए। मेरे मामले में संदर्भ को जोड़े बिना एक त्रुटि लौटाना 'सबसे आम स्थिति' नहीं है। यह विपरीत है :)

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

ज़रूर, लेकिन मुझे आशा है कि आप समझते हैं कि try बिना किसी संदर्भ के त्रुटि वापस करने के लिए नहीं है। वास्तव में, संदर्भ जोड़ने का सबसे आम मामला (प्रति फ़ंक्शन एक संदर्भ) try द्वारा बहुत सरल है:

func doSomething() (err error) {
    defer fmt.HandleErrorf(&err, "doing something")

    x := try(oneThing())
    try(anotherThing(x))
    // ...
}

एहसास करने वाली बात यह है कि ज्यादातर समय, oneThing() और anotherThing() अपने आप में एक पर्याप्त संदर्भ लौटाएगा, इसलिए इसे एक साधारण "doing something: ..." में लपेटना पूरी तरह से पर्याप्त है।

एक साइड नोट के रूप में मुझे लगता है कि हम सजावट के लिए _who_ पर कुछ सम्मेलनों का उपयोग कर सकते हैं। Stdlib में कुछ फ़ंक्शन ऐसा करते हैं, पूर्व copy: x to y या इसी तरह, मैं व्यक्तिगत रूप से कॉलर तक सजावट छोड़ रहा हूं, क्योंकि इसमें तर्क हैं।

उदाहरण के लिए यदि मेरे पास Copy() होता तो मैं return errors.Wrap(err, "writing") जैसा कुछ करता और Copy() का उपयोग करने वाला कॉलर errors.Wrapf(err, "copying from %v to %v", src, dst) या इसी तरह के साथ लपेटता।

ये दोनों बहुत अच्छी तरह से मेल नहीं खाते हैं, और कभी-कभी डुप्लिकेट स्ट्रिंग्स के साथ समाप्त हो सकते हैं, क्या यह कहना सबसे अच्छा है कि stdlib शैली मुहावरेदार है? हालांकि मुझे याद नहीं कि वे सभी इस तरह का व्यवहार कर रहे हों। मुझे लगता है कि यही एकमात्र तरीका है @faiface का उदाहरण पर्याप्त होगा। हो सकता है कि मैं समस्या को उलट रहा हूं, मेरे लिए यह कम करने के लिए क्लीनर महसूस करता है और फोन करने वाले को निर्णय छोड़ देता है, खासकर "बस के मामले में" वे प्रासंगिक जानकारी को छोड़ देते हैं।

मैं व्यक्तिगत रूप से सजावट को कॉलर तक छोड़ रहा हूं, क्योंकि इसमें तर्क हैं।

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

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

@lpar माइंड

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

@lpar ठीक है, तो यह एक और उदाहरण है जहां if err != nil उपयोग में रहेगा। या आप अपने तर्क को कई कार्यों में विभाजित करते हैं।

लेकिन समझें कि एक उदाहरण देना जहां try उपयुक्त नहीं है, try खिलाफ तर्क नहीं है। try सभी त्रुटि प्रबंधन को प्रतिस्थापित करने के लिए नहीं है, केवल सबसे सामान्य मामले हैं।

@ abejide001 try प्रस्ताव कई अन्य भाषाओं से पारंपरिक "कोशिश/पकड़" नहीं है, यह जंग में try! मैक्रो के समान है। अच्छा मेम हालांकि lol

ओह - गलत मुद्दे पर पोस्ट किया गया। https://github.com/golang/go/issues/32437#issuecomment -509024693 पर ले जाया गया।

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

अंश:

• _The check मैक्रो एक एक लाइनर नहीं है: यह सबसे अधिक है जहाँ कई दोहराव में मदद करता है
  एक ही अभिव्यक्ति का उपयोग करते हुए जांच निकटता में की जानी चाहिए।_
• _इसका निहित संस्करण पहले से ही खेल के मैदान में

डिजाइन बाधाएं (मिली)

यह एक अंतर्निहित है, यह एक पंक्ति में घोंसला नहीं बनाता है, यह try से अधिक प्रवाह की अनुमति देता है और इसमें कोड के आकार के बारे में कोई अपेक्षा नहीं है। यह नग्न रिटर्न को प्रोत्साहित नहीं करता है।

उपयोग उदाहरण

// built-in 'check' macro signature: 
func check(Condition bool) {}

check(err != nil) // explicit catch: label.
{
    ucred, err := getUserCredentials(user)
    remote, err := connectToApi(remoteUri)
    err, session, usertoken := remote.Auth(user, ucred)
    udata, err := session.getCalendar(usertoken)

  catch:               // sad path
    ucred.Clear()      // cleanup passwords
    remote.Close()     // do not leak sockets
    return nil, 0, err // dress before leaving
}
// happy path

// implicit catch: label is above last statement
check(x < 4) 
  {
    x, y = transformA(x, z)
    y, z = transformB(x, y)
    x, y = transformC(y, z)
    break // if x was < 4 after any of above
  }

आशा है कि यह मदद करता है, आनंद लें!

लेकिन समझें कि एक उदाहरण देना जहां try उपयुक्त नहीं है, try खिलाफ तर्क नहीं है। try सभी त्रुटि प्रबंधन को प्रतिस्थापित करने के लिए नहीं है, केवल सबसे सामान्य मामले हैं।

और मेरे द्वारा पहले पोस्ट किए गए आँकड़ों के अनुसार, वे मेरे कोड में सबसे आम मामले नहीं हैं। मेरे कोड में सबसे आम मामलों में वापसी से पहले त्रुटियों को लपेटा जा रहा है। तो try मेरी त्रुटि रिटर्न के केवल एक अंक प्रतिशत के लिए उपयुक्त होगा (*), यही कारण है कि मुझे लगता है कि हमें कुछ बेहतर चाहिए।

(*) और वास्तव में, मुझे लगता है कि नग्न err वापसी उदाहरणों में त्रुटियां होने की संभावना है जिन्हें ठीक किया जाना चाहिए।

पूरी तरह से सहमत हैं, "अगर गलत है! = शून्य" अकेला छोड़ दें।

@ abejide001 try प्रस्ताव कई अन्य भाषाओं से पारंपरिक "कोशिश/पकड़" नहीं है, यह जंग में try! मैक्रो के समान है। अच्छा मेम हालांकि lol

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

@ जैसा कि मैं यह नहीं कह रहा था कि फीचर को सही ठहराने के लिए, मैं सिर्फ यह स्पष्ट करने के लिए कह रहा था कि फीचर ने क्या किया। मैं try प्रस्ताव के बीच में हूं।

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

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

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

@icholi ने लिखा:

अधिक सुव्यवस्थित त्रुटि प्रबंधन (वार्षिक सर्वेक्षण से) का अनुरोध करने वाली भारी सामुदायिक प्रतिक्रिया थी। गो टीम अब उस मुद्दे को संबोधित कर रही है।

मैंने अभी यहां सर्वेक्षण देखा: https://blog.golang.org/survey2018-results

जाहिरा तौर पर सवाल यह था: "आज गो का उपयोग करके आप व्यक्तिगत रूप से सबसे बड़ी चुनौती क्या हैं?" संभावित उत्तर "त्रुटि प्रबंधन" के साथ।

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

मेरा सुझाव सभी त्रुटि प्रबंधन प्रस्तावों से पीछे हटना होगा (प्रभावी रूप से @miekg क्या सुझाव दे रहा था)। और पहले यह निर्धारित करें कि समुदाय वास्तव में क्या चाहता है, उसका दस्तावेजीकरण करें। फिर पता करें कि वे ऐसा क्यों चाहते हैं। और उसके बाद ही इसे प्राप्त करने के तरीकों को देखना शुरू करें।

मैं अभी कोशिश प्रस्ताव के माध्यम से जा रहा हूं, लेकिन जब तक मुझे कुछ याद नहीं आ रहा है, यह कहने के लिए उपेक्षा करता है _why_ यह प्रस्तावित किया जा रहा है, "बॉयलरप्लेट को खत्म करने के लिए अगर बयान [...}" के अलावा। लेकिन इस बात का कोई उल्लेख नहीं है कि बयान आवश्यक होने पर उन बॉयलरप्लेट को क्यों खत्म किया जाए।

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

यहां लोग try खिलाफ बहस कर रहे हैं क्योंकि उन्हें लगता है कि सभी लौटाई गई त्रुटियों को एनोटेट किया जाना चाहिए। वास्तविकता यह है कि, कोड के वर्तमान कोष (मानक पुस्तकालय सहित) में, त्रुटि जांच के एक उच्च प्रतिशत में ~ नंगे ~ गैर-एनोटेटेड त्रुटि रिटर्न हैं और try से लाभान्वित होंगे। कोड कैसे होना चाहिए, इस बारे में आपकी धारणा का कोड IS के तरीके से कोई लेना-देना नहीं

@icholi त्रुटियों को अनदेखा करना इंगित करता है कि देव उस त्रुटि की परवाह नहीं करता है। त्रुटि नगण्य है या कॉलर द्वारा असंभव माना जाता है। यदि ऐसा है तो "कोशिश" उतना ही व्यर्थ है, कॉलर बस "कोशिश" में फ़ंक्शन को लपेट नहीं पाएगा।

मेरा सुझाव सभी त्रुटि प्रबंधन प्रस्तावों से पीछे हटना होगा (प्रभावी रूप से @miekg क्या सुझाव दे रहा था)। और पहले यह निर्धारित करें कि समुदाय वास्तव में क्या चाहता है, उसका दस्तावेजीकरण करें। फिर पता करें कि वे ऐसा क्यों चाहते हैं। और उसके बाद ही इसे प्राप्त करने के तरीकों को देखना शुरू करें।

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

मैं अधिक विस्तार से जानना चाहता हूं कि व्यापक गो समुदाय वास्तव में किसी भी प्रस्तावित नई त्रुटि प्रबंधन सुविधा से क्या चाहता है।

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

यदि लोग भाग लेना चाहते हैं, तो यह लिंक साझा करने के लिए छोटा किया गया है:

https://forms.gle/gaCBgxKRE4RMCz7c7

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

@ लेन-सी-वैगनर क्या आप यह कहने की कोशिश कर रहे हैं कि एक गैर-एनोटेटेड त्रुटि लौटाना वही है जो इसे वापस नहीं कर रहा है? संपादित करें: निश्चित पिछली टिप्पणी

@icholy आह मुझे गलत समझा। जब आपने "नंगे" कहा तो मैंने सोचा कि आपका मतलब "_" त्रुटियों को अनदेखा कर रहा है।

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

कृपया यह कहना बंद करें कि "हर कोई अनदेखा करने के लिए स्वतंत्र है" try । हम दूसरों द्वारा लिखे गए कोड को पढ़ते हैं।

@tv42 मुझे नहीं पता कि आप मुझे यहां संबोधित कर रहे

@griesemer आपके सर्वेक्षण में भारी कमी थी। मैंने त्रुटि प्रबंधन के लिए मतदान किया था, लेकिन मेरा मतलब था कि पूर्ण प्रकार की सुरक्षा थी, वर्बोसिटी नहीं। बेहतर होगा कि आप केवल त्रुटियों के बारे में एक और बनाएं।

और मुझे अभी भी योग प्रकार चाहिए।

यह उस तरीके के बारे में एक प्रस्ताव है जिस तरह से gofmt वर्तमान में फ़ॉर्मेट करता है यदि त्रुटि != nil

(यह कोशिश () प्रस्ताव के बारे में एक राय नहीं है।)

जब कोई कथन एक-पंक्ति शून्य त्रुटि मान देता है, जैसे:

err := myFunc()
if err != nil {
    return err
}

gofmt अपने स्वयं के if-statement नियम को शिथिल कर सकता है और इसे इस तरह एक पंक्ति में प्रारूपित कर सकता है:

err := myFunc()
if err != nil { return err }

त्रुटि प्रबंधन कोड की तीन पंक्तियाँ केवल एक पंक्ति बन जाती हैं। कम अव्यवस्था। कार्यक्रम प्रवाह का पालन करना आसान है।

इसके साथ रेखा कहाँ खींचनी है (सजा स्वीकृत) के बारे में कुछ निर्णय लेने की आवश्यकता होगी
गोफएमटी नियम में बदलाव इसमें कुछ सजावट शामिल हो सकती है, जैसे:

err := myFunc()
if err != nil { return fmt.Errorf("myFunc() blew up! %v", err }

लेकिन विस्तृत बहु-पंक्ति त्रुटि प्रबंधन यथावत रहना चाहिए: बहु-पंक्ति और स्पष्ट और स्पष्ट।

_try_ प्रस्ताव वापस ले लिया गया है: https://github.com/golang/go/issues/32437#issuecomment -512035919

जेनरिक कोई?

यह उस तरीके के बारे में एक प्रस्ताव है जिस तरह से gofmt वर्तमान में फ़ॉर्मेट करता है यदि त्रुटि != nil

मैंने कोशिश की है कि, बहु लाइन स्वरूपण की तुलना में कोड उस तरह से और भी अपठनीय है। कोशिश उस समाधान से काफी बेहतर है।

आईएमओ यहां समस्या यह नहीं है कि त्रुटि प्रबंधन अनदेखा किया जाता if err != nil सिंटैक्स को वैसे ही छोड़ना संभव नहीं होगा, लेकिन Error रिटर्न की अज्ञानता को सीमित करें? जैसे इसे विरासत कोड के लिए डिसेवरिटी विकल्प के साथ एक कंपाइलर चेतावनी/त्रुटि बनाना।

आईएमओ यहां समस्या यह नहीं है कि त्रुटि प्रबंधन अनदेखा किया जाता if err != nil सिंटैक्स को वैसे ही छोड़ना संभव नहीं होगा, लेकिन Error रिटर्न की अज्ञानता को सीमित करें? जैसे इसे विरासत कोड के लिए डिसेवरिटी विकल्प के साथ एक कंपाइलर चेतावनी/त्रुटि बनाना।

बहुत से लोग चाहते हैं कि एक लिंटर अनदेखी त्रुटियों को दिखाए।

मैं इसे एक कठिन त्रुटि बनाना पसंद करूंगा, लेकिन पहले से ही लिखित विरासत के टन को देखते हुए, लिटर भी उचित है।

मुझे लगता है कि https://github.com/kisielk/errcheck मुझे अनहेल्ड त्रुटियों के बारे में बताने के लिए मूल्यवान है @sorenvonsarvort

जैसा कि #32437 पर चर्चा में देखा गया, इस प्रस्ताव को अभी के लिए स्वीकार कर लिया गया है। समापन। यदि फिर से समस्या उत्पन्न होती है, तो एक नया प्रस्ताव खोला जा सकता है।

मुझे लगता है कि एक कारण यह है कि बहुत सारे प्रस्ताव ऐसा महसूस करते हैं कि वे बिल्कुल सही नहीं हैं क्योंकि वे वास्तव में एक ही समय में दो अलग-अलग समस्याओं का समाधान करने की कोशिश कर रहे हैं। एक तरफ, यह सच है कि लगभग हर फ़ंक्शन कॉल के बाद err != nil ब्लॉक होने से कोड के प्रवाह को अजीब तरीके से तोड़ दिया जा सकता है, हालांकि इसमें निश्चित रूप से इसके अपसाइड हैं, लेकिन मुझे लगता है कि यह केवल आधा है संकट। दूसरा मुद्दा यह है कि कई रिटर्न को संभालना, भले ही इसमें त्रुटियां शामिल हों या नहीं, काफी भद्दा हो सकता है।

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

मुझे नहीं पता। शायद यह सिर्फ मैं हूँ। लेकिन मैंने अब लगभग 10 वर्षों से गो का उपयोग किया है और कई रिटर्न के साथ कॉलिंग फ़ंक्शन अभी भी मुझे कभी-कभी अजीब लगता है।

शुक्रिया!

वहाँ के साथ एक वास्तव में मुद्दा है if err != nil , के दायरे err यह होना चाहिए की तुलना में लंबे समय तक रह सकते हैं। जब आप if इनलाइन करते हैं तो यह समस्या का समाधान करता है, लेकिन सभी मामलों को इनलाइन नहीं किया जा सकता है।

if err := foo(); err != nil {

if _, err := bar(); err != nil {



md5-6a135eb952fe7b24b3389cb16d3244a1



a, err := bar()
if err != nil {



md5-d52f811d3e31bb368bd8045cfb2e93b4



var err error
baz.A, err = bar()
if err != nil {

if err != nil {} ब्लॉक पूर्ण होने के बाद err चर फ़ंक्शन स्कोप में मौजूद नहीं होना चाहिए। यहाँ मेरा प्रस्ताव है जो समस्या को ठीक करने के लिए try() प्रस्ताव का निर्माण करता है https://github.com/golang/go/issues/33161। मुझे कुछ रचनात्मक प्रतिक्रिया पसंद आएगी।

इर एरर != nil {} ब्लॉक पूरा होने के बाद एरर वेरिएबल फंक्शन स्कोप में मौजूद नहीं होना चाहिए।

अगर ब्लॉक पूरा होने के बाद यह "मौजूद" क्यों नहीं होना चाहिए? संकलक इसके लिए अनुकूलन कर सकता है (यदि यह आवश्यक समझे), और कोई मानसिक भार नहीं है जब त्रुटि := stmt()\nif err != nil {} ब्लॉक पूर्ण हो जाता है क्योंकि ये लगभग हमेशा एक साथ चलते हैं।

मैंने अभी तक आपके प्रस्ताव को गहराई से नहीं देखा है (हालांकि एक लिखने के प्रयास के माध्यम से जाने के लिए यश!) हालाँकि, जैसा कि मैंने ऊपर अपनी टिप्पणी में भी उल्लिखित किया है, मुझे लगता है कि किसी भी कथित समस्या में अधिक शोध की आवश्यकता है, इससे पहले कि हम उन्हें हल करने के लिए किसी भी प्रस्ताव पर खुदाई करें।

@Freeaqingme त्रुटियाँ if err != nil ब्लॉक पूर्ण होने के बाद मौजूद नहीं होनी चाहिए, ज्यादातर इसलिए क्योंकि हम पहले से ही ऐसा कार्य करते हैं जैसे यह नहीं करता है।

CopyFile उदाहरण में, r, err := os.Open(src) बाद w, err := os.Create(dst) । दूसरा err पहले वाले को छायांकित कर रहा है। शैडोइंग वेरिएबल्स को आमतौर पर फहराया जाता है।

अन्य विषमताएँ भी हैं। अगर मेरे पास err := foo() और बाद में bar.V, err = baz() जैसा कुछ है, अगर कोड को दोबारा किया जाता है और मुझे अब foo() की आवश्यकता नहीं है, तो मुझे baz से पहले var err error जोड़ने की आवश्यकता होगी baz लाइन। . मुझे नहीं लगता कि किसी फ़ंक्शन में किसी भिन्न स्थान को दोबारा करने से उस तरह के अन्य स्थानों को प्रभावित करना चाहिए।

तकनीकी रूप से

    r, err := os.Open(src)
    if err != nil {
        return ...
    }
    w, err := os.Create(dst)

err का दूसरा उदाहरण पहले उदाहरण को छाया नहीं देता है। वे वास्तव में एक ही चर हैं। https://golang.org/ref/spec#Short_variable_declarations पर चरों को फिर से घोषित करने की चर्चा देखें

func doSomeThing() {
आर, गलती: = ओएस ओपन (फ़ाइल नाम)
पैनिक (fmt.Errorf (गलती, "फ़ाइल खोलने में विफल:% s", फ़ाइल नाम)) //
यहाँ दहशत है।

}

गुरु 10 अक्टूबर, 2019 11:24 clearcode पर पर [email protected] लिखा है:

मुझे लगता है कि हम एक बिल्डिन फ़ंक्शन जोड़ सकते हैं:

जोर देना ()

उदाहरण:

func doSomeThing () त्रुटि {

r, err := os.Open(filename)
assert(err, "failed to open file: %s", filename) // in this step, just return the error

सम्मान, त्रुटि: = http.Get(someURL)
जोर दें (गलती, "अनुरोध विफल")

}

और एक अन्य फ़ंक्शन जो एक त्रुटि नहीं लौटाता है:

func doSomeThing() {
आर, गलती: = ओएस ओपन (फ़ाइल नाम)
जोर दें (गलती, "फ़ाइल खोलने में विफल:% s", फ़ाइल नाम) // यहाँ घबराहट है।

}

तो जोर दें (त्रुटि, तर्क ... इंटरफ़ेस {}) इससे बेहतर है: अगर गलती! = शून्य; {
वापसी गलती}

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/32825?email_source=notifications&email_token=AGUV7XQ5HO7GL3YP72R7BV3QN2N55A5CNFSM4H4DL33KYY3PNVWWWK3TUL52HS4DFVREXGEA43VMVBW1#TNIMV-5KW240JLOK
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AGUV7XS4JMK44QHIIR3RSGTQN2N55ANCNFSM4H4DL33A
.

टेकअवे यह है कि मैं वर्तमान में लौटाई गई वास्तविक त्रुटि देखना चाहता हूं
वर्तमान लाइन में कार्य करें।

शुक्र, 11 अक्टूबर, 2019 को सुबह 9:55 बजे आआ इनाई [email protected] ने लिखा:

func doSomeThing() {
आर, गलती: = ओएस ओपन (फ़ाइल नाम)
पैनिक (fmt.Errorf (गलती, "फ़ाइल खोलने में विफल:% s", फ़ाइल नाम)) // यहाँ दहशत है।

}

गुरु 10 अक्टूबर, 2019 11:24 clearcode पर पर [email protected]
लिखा था:

मुझे लगता है कि हम एक बिल्डिन फ़ंक्शन जोड़ सकते हैं:

जोर देना ()

उदाहरण:

func doSomeThing () त्रुटि {

r, err := os.Open(filename)
assert(err, "failed to open file: %s", filename) // in this step, just return the error

सम्मान, त्रुटि: = http.Get(someURL)
जोर दें (गलती, "अनुरोध विफल")

}

और एक अन्य फ़ंक्शन जो एक त्रुटि नहीं लौटाता है:

func doSomeThing() {
आर, गलती: = ओएस ओपन (फ़ाइल नाम)
जोर दें (गलती, "फ़ाइल खोलने में विफल:% s", फ़ाइल नाम) // यहाँ घबराहट है।

}

तो जोर दें (त्रुटि, तर्क ... इंटरफ़ेस {}) इससे बेहतर है: अगर गलती! = शून्य; {
वापसी गलती}

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/32825?email_source=notifications&email_token=AGUV7XQ5HO7GL3YP72R7BV3QN2N55A5CNFSM4H4DL33KYY3PNVWWWK3TUL52HS4DFVREXGEA43VMVBW1#TNIMV-5KW240JLOK
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AGUV7XS4JMK44QHIIR3RSGTQN2N55ANCNFSM4H4DL33A
.

सच कहूं तो, मैं एक निहित प्रतिफल नहीं चाहता जो try प्रदान करता है। अगर हमारे पास जेनेरिक होते, तो मैं ऐसे समाधान को पसंद करता जो इसके बजाय मोनैड-ईश व्यवहार का उपयोग करता।

type Result<T> interface {
  Expect(err error) T
  OrElse(defaultValue T) T
}

func From<T>(value T, err error) Result<T> { ... }

मेरे लिए, यह वर्तमान में प्रस्तावित बिल्टिन की तुलना में बहुत साफ है, हालांकि उपरोक्त में और बदलाव की आवश्यकता होगी क्योंकि आपके पास लौटाए गए तरीकों का प्रसार होगा (मूल्य, त्रुटि) और परिणाम

यह रस्ट के ओके और एर के समान है।
मुझे लगता है कि if err != nil {} शायद थोड़ा बेहतर हो।

@Yanwenjiepy यह जानबूझकर है, मैं रस्ट के Result प्रकार का बहुत बड़ा प्रशंसक हूं।

मुझे गो सीखने में 10 मिनट से भी कम समय लगा है। जिस कोड को मैं देख रहा था उसमें सबसे पहली चीज जो मैंने देखी थी, वह यह थी कि इस प्रति को बार-बार चिपकाया गया था:

someValue, err := someFunction();
if err != nil {
  panic(err)
}

मैं स्पष्ट रूप से एक विशेषज्ञ नहीं हूं, लेकिन यह महत्वपूर्ण हो सकता है कि इस धागे पर समाप्त होने के लिए मुझे केवल मेरी पहली नज़र लग गई है।

ऐसा इसलिए है क्योंकि आप सीखने के लिए कोड स्निपेट देख रहे हैं। वास्तविक कोड को केवल घबराहट और दुर्घटना ही नहीं, बल्कि त्रुटियों को संभालना होता है।

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

try {
  foo, throw err := someFunction();
  bar, throw err := foo.get();
  baz, throw err := bar.make();
  qux, throw err := baz.transform();
} catch(err) {
  // "Unable to foo bar baz qux."
  tryHarder();
}

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

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

लिंक के लिए धन्यवाद। errWriter एक पूरी तरह से प्रचलित समाधान है।

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

try {
  foo, throw err := someFunction();
  bar, throw err := foo.get();
  baz, throw err := bar.make();
  qux, throw err := baz.transform();
} catch(err) {
  // "Unable to foo bar baz qux."
  tryHarder();
}

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

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

try {
  foo, throw err := someFunction();  // err could be TypeA and TypeB
  bar, throw err := foo.get();       // err could be TypeB and TypeC
  baz, throw err := bar.make();      // err could be TypeA and TypeC
  qux, throw err := baz.transform(); // err could be TypeB and TypeD
} catch(err) {
  tryHarder(); // tell me how to handle each error?
}

नीचे दिए गए कोड को समझने में किसी और को केवल 1 मिनट का समय लगेगा:

foo, err := someFunction();  // err could be TypeA and TypeB
if err != nil {
 // handle err
}

bar, err := foo.get();       // err could be TypeB and TypeC
if err != nil {
  // handle err
}

baz, err := bar.make();      // err could be TypeA and TypeC
if err != nil {
  // handle err
}

qux, err := baz.transform(); // err could be TypeB and TypeD
if err != nil {
  // handle err
}

मान लें कि प्रत्येक फ़ंक्शन अतिव्यापी त्रुटि प्रकार देता है और आपको सभी फ़ंक्शन परिणामों को इनायत से संभालना चाहिए

उस उदाहरण में, आप बिल्कुल सही हैं।