मैं मानता हूं कि यह आगे बढ़ने का सबसे अच्छा तरीका है: एक साधारण डिजाइन के साथ सबसे आम समस्या को ठीक करना।

मैं बाइकशेड नहीं करना चाहता (इस बातचीत को स्थगित करने के लिए स्वतंत्र महसूस करें), लेकिन रस्ट वहां गया और अंततः बढ़ी हुई पठनीयता के लिए, एक बिल्टिन फ़ंक्शन के बजाय ? पोस्टफिक्स ऑपरेटर के साथ बस गया।

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

check io.Copy(w, check newReader(foo))

इसके बजाय:

io.Copy(w, newReader(foo)?)?

लेकिन अब हमारे पास होगा:

try(io.Copy(w, try(newReader(foo))))

जो मुझे लगता है कि यह स्पष्ट रूप से तीनों में से सबसे खराब है, क्योंकि यह अब भी स्पष्ट नहीं है कि मुख्य कार्य कौन सा कहा जा रहा है।

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

स्पष्टीकरण देना:

करता है

func f() (n int, err error) {
  n = 7
  try(errors.New("x"))
  // ...
}

वापसी (0, "एक्स") या (7, "एक्स")? मैं बाद वाला मानूंगा।

क्या त्रुटि वापसी का नाम उस मामले में रखा जाना चाहिए जहां कोई सजावट या हैंडलिंग नहीं है (जैसे आंतरिक सहायक फ़ंक्शन में)? मैं नहीं मानूंगा।

आपका उदाहरण 7, errors.New("x") लौटाता है। शीघ्र ही सबमिट किए जाने वाले पूर्ण दस्तावेज़ में यह स्पष्ट होना चाहिए (https://golang.org/cl/180557)।

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

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

मुझे पोस्टफ़िक्स ? दिखने का तरीका पसंद नहीं है, लेकिन मुझे लगता है कि यह अभी भी try() देता है।

संपादित करें: ठीक है, मैं पूरी तरह से भूल गया कि घबराहट मौजूद है और यह कोई कीवर्ड नहीं है।

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

@dominikh विस्तृत प्रस्ताव इस पर विस्तार से चर्चा करता है, लेकिन कृपया ध्यान दें कि panic और recover दो बिल्ट-इन हैं जो नियंत्रण प्रवाह को भी प्रभावित करते हैं।

सुधार के लिए एक स्पष्टीकरण/सुझाव:

if the last argument supplied to try, of type error, is not nil, the enclosing function’s error result variable (...) is set to that non-nil error value before the enclosing function returns

क्या यह इसके बजाय is set to that non-nil error value and the enclosing function returns कह सकता है? (एस/पहले/और)

पहली बार पढ़ने पर, before the enclosing function returns ऐसा लग रहा था कि यह _eventually_ फ़ंक्शन के वापस आने से ठीक पहले भविष्य में किसी बिंदु पर त्रुटि मान सेट करेगा - संभवतः बाद की पंक्ति में। सही व्याख्या यह है कि कोशिश वर्तमान फ़ंक्शन को वापस करने का कारण बन सकती है। यह वर्तमान भाषा के लिए एक आश्चर्यजनक व्यवहार है, इसलिए एक स्पष्ट पाठ का स्वागत किया जाएगा।

मुझे लगता है कि यह सिर्फ चीनी है, और कुछ मुखर विरोधियों ने गोलंग को if err != nil ... टाइपिंग के बार-बार उपयोग के बारे में चिढ़ाया और किसी ने इसे गंभीरता से लिया। मुझे नहीं लगता कि यह कोई समस्या है। ये दो बिल्ट-इन केवल गायब चीजें हैं:

https://github.com/purpleidea/mgmt/blob/a235b760dc3047a0d66bb0b9d63c25bc746ed274/util/errwrap/errwrap.go#L26

निश्चित नहीं है कि कोई भी इस तरह से एक फ़ंक्शन क्यों लिखेगा, लेकिन इसके लिए अनुमानित आउटपुट क्या होगा

try(foobar())

अगर foobar वापस (error, error)

मैं नियंत्रण प्रवाह के बारे में अपनी पिछली चिंताओं को वापस लेता हूं और अब मैं ? का उपयोग करने का सुझाव नहीं देता। मैं घुटने के बल प्रतिक्रिया के लिए क्षमा चाहता हूं (हालांकि मैं यह बताना चाहता हूं कि ऐसा नहीं होता यदि मुद्दा _after_ पूर्ण प्रस्ताव उपलब्ध था) दायर किया गया होता।

मैं सरलीकृत त्रुटि प्रबंधन की आवश्यकता से असहमत हूं, लेकिन मुझे यकीन है कि यह एक हारी हुई लड़ाई है। try जैसा कि प्रस्ताव में निर्धारित किया गया है, ऐसा करने का कम से कम बुरा तरीका प्रतीत होता है।

@webermaster केवल अंतिम error परिणाम try को पारित अभिव्यक्ति के लिए विशेष है, जैसा कि प्रस्ताव दस्तावेज़ में वर्णित है।

@dominikh की तरह, मैं भी सरलीकृत त्रुटि प्रबंधन की आवश्यकता से असहमत हूं।

यह लंबवत जटिलता को क्षैतिज जटिलता में ले जाता है जो शायद ही कभी एक अच्छा विचार है।

अगर मुझे त्रुटि प्रबंधन प्रस्तावों को सरल बनाने के बीच चयन करना था , हालांकि, यह मेरा पसंदीदा प्रस्ताव होगा।

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

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

मैं केवल यह व्यक्त करना चाहता हूं कि मुझे लगता है कि एक नंगे try(foo()) वास्तव में कॉलिंग फ़ंक्शन से बाहर निकलने से हम दृश्य क्यू से दूर हो जाते हैं कि परिणाम के आधार पर फ़ंक्शन प्रवाह बदल सकता है।

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

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

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

1. समारोह की शुरुआत में err घोषित करें।
   क्या यह काम करता हैं? मुझे आस्थगित और अनाम परिणामों वाली समस्याएं याद हैं। यदि ऐसा नहीं है तो प्रस्ताव को इस पर विचार करने की आवश्यकता है।

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

1. मान असाइन करें जैसे हमने अतीत में किया था, लेकिन एक सहायक wrapf फ़ंक्शन का उपयोग करें जिसमें if err != nil बॉयलरप्लेट हो।

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

अगर कोई काम करता है, तो मैं उससे निपट सकता हूं।

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

यह काम नहीं करेगा। डिफर स्थानीय err वैरिएबल को अपडेट करेगा, जो रिटर्न वैल्यू से असंबंधित है।

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

यह काम करना चाहिए। हालांकि, यह शून्य त्रुटि पर भी रैप को कॉल करेगा।
यह भी काम करेगा (जारी रहेगा), और आईएमओ बहुत स्पष्ट है:

func sample() (string, error) {
  s, err := f()
  if err != nil {
      return "", wrap(err)
  }
  return s, nil
}

कोई भी आपको try का उपयोग नहीं करने वाला है।

निश्चित नहीं है कि कोई भी इस तरह से एक फ़ंक्शन क्यों लिखेगा, लेकिन इसके लिए अनुमानित आउटपुट क्या होगा

try(foobar())

अगर foobar वापस (error, error)

आप किसी फ़ंक्शन से एक से अधिक त्रुटि क्यों लौटाएंगे? यदि आप फ़ंक्शन से एक से अधिक त्रुटि लौटा रहे हैं, तो शायद फ़ंक्शन को पहले दो अलग-अलग में विभाजित किया जाना चाहिए, प्रत्येक केवल एक त्रुटि लौटा रहा है।

क्या आप एक उदाहरण के साथ विस्तार कर सकते हैं?

@cespare : किसी के लिए go fix लिखना संभव होना चाहिए जो $#$1 try #$ के लिए उपयुक्त मौजूदा कोड को फिर से लिखता है जैसे कि यह try का उपयोग करता है। यह महसूस करना उपयोगी हो सकता है कि मौजूदा कोड को कैसे सरल बनाया जा सकता है। हम कोड आकार या प्रदर्शन में किसी भी महत्वपूर्ण बदलाव की उम्मीद नहीं करते हैं, क्योंकि try सिर्फ वाक्यात्मक चीनी है, एक सामान्य पैटर्न को स्रोत कोड के एक छोटे टुकड़े से बदल देता है जो अनिवार्य रूप से समान आउटपुट कोड उत्पन्न करता है। यह भी ध्यान दें कि try का उपयोग करने वाला कोड एक ऐसे गो संस्करण का उपयोग करने के लिए बाध्य होगा जो कम से कम वह संस्करण है जिस पर try पेश किया गया था।

@lestrrat : सहमत हैं कि किसी को यह सीखना होगा कि try नियंत्रण प्रवाह को बदल सकता है। हमें संदेह है कि आईडीई इसे आसानी से पर्याप्त रूप से उजागर कर सकता है।

@ गुडवाइन : जैसा कि @ Randall77 ने पहले ही बताया है, आपका पहला सुझाव काम नहीं करेगा। एक विकल्प के बारे में हमने सोचा है (लेकिन दस्तावेज़ में चर्चा नहीं की गई है) कुछ पूर्व-घोषित चर होने की संभावना है जो error परिणाम को दर्शाता है (यदि कोई पहले स्थान पर मौजूद है)। इससे उस परिणाम का नामकरण करने की आवश्यकता समाप्त हो जाएगी ताकि इसका उपयोग defer में किया जा सके। लेकिन वह और भी जादू होगा; यह उचित नहीं लगता। रिटर्न परिणाम का नामकरण करने में समस्या अनिवार्य रूप से कॉस्मेटिक है, और जहां यह सबसे ज्यादा मायने रखता है वह ऑटो-जेनरेटेड एपीआई में go doc और दोस्तों द्वारा परोसा जाता है। उन उपकरणों में इसे संबोधित करना आसान होगा (इस विषय पर विस्तृत डिज़ाइन दस्तावेज़ के अक्सर पूछे जाने वाले प्रश्न भी देखें)।

@nictuku : स्पष्टीकरण के लिए आपके सुझाव के बारे में (एस/पहले/और/): मुझे लगता है कि जिस अनुच्छेद का आप जिक्र कर रहे हैं उससे ठीक पहले कोड यह स्पष्ट करता है कि वास्तव में क्या होता है, लेकिन मैं आपका बिंदु देखता हूं, एस/पहले/और/मई गद्य को स्पष्ट करें। मैं बदलाव करूंगा।

सीएल 180637 देखें।

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

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

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

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

func CopyFile(src, dst string) error {
    defer func() {
        err = fmt.Errorf("copy %s %s: %v", src, dst, err)
    }()
    r, err := try(os.Open(src))
    defer r.Close()

    w, err := try(os.Create(dst))

    defer w.Close()
    defer os.Remove(dst)
    try(io.Copy(w, r))
    try(w.Close())

    return nil
}

आप इसे पहली नज़र में देख सकते हैं और सोच सकते हैं कि यह बेहतर दिखता है, क्योंकि बहुत कम दोहराया गया कोड है। हालांकि, पहले उदाहरण में फ़ंक्शन द्वारा लौटाए गए सभी स्पॉट को खोजना बहुत आसान था। वे सभी इंडेंट किए गए थे और return से शुरू हुए थे, उसके बाद एक स्पेस था। यह इस तथ्य के कारण है कि सभी सशर्त रिटर्न _must_ सशर्त ब्लॉक के अंदर होने चाहिए, जिससे gofmt मानकों द्वारा इंडेंट किया जा सके। return भी, जैसा कि पहले कहा गया है, किसी फ़ंक्शन को यह कहे बिना छोड़ने का एकमात्र तरीका है कि एक भयावह त्रुटि हुई। दूसरे उदाहरण में, केवल एक ही return है, इसलिए ऐसा लगता है कि केवल एक चीज है कि फ़ंक्शन _ever_ को वापस लौटना चाहिए nil । अंतिम दो try कॉल देखने में आसान हैं, लेकिन पहले दो थोड़े कठिन हैं, और यदि वे कहीं नेस्ट किए गए हों, तो और भी कठिन होंगे, जैसे proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) ।

ऐसा लगता है कि किसी समारोह से लौटना एक "पवित्र" चीज है, यही वजह है कि मैं व्यक्तिगत रूप से सोचता हूं कि किसी समारोह के सभी निकास बिंदुओं को return द्वारा चिह्नित किया जाना चाहिए।

किसी ने इसे 5 साल पहले ही लागू कर दिया है। यदि आप रुचि रखते हैं, तो आप कर सकते हैं
इस सुविधा का प्रयास करें

https://news.ycombinator.com/item?id=20101417

मैंने एएसटी प्रीप्रोसेसर के साथ पांच साल पहले गो में कोशिश() लागू की और वास्तविक परियोजनाओं में इसका इस्तेमाल किया, यह बहुत अच्छा था: https://github.com/lunixbochs/og

त्रुटि-जांच-भारी कार्यों में इसका उपयोग करने के कुछ उदाहरण यहां दिए गए हैं: https://github.com/lunixbochs/poxd/blob/master/tls.go#L13

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

@griesemer
त्रुटि रैपिंग को संभालने के तरीके के रूप में defer के आपके प्रस्तावित उपयोग के साथ मेरी समस्या यह है कि मेरे द्वारा दिखाए गए स्निपेट से व्यवहार (नीचे दोहराया गया) बहुत आम AFAICT नहीं है, और क्योंकि यह बहुत दुर्लभ है तो मैं कल्पना कर सकता हूं कि लोग इस सोच को लिख रहे हैं यह काम करता है जब यह नहीं होता है।

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

var err error
defer fmt.HandleErrorf(err);

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

या... इस तरह defer का उपयोग करने का सुझाव न दें, कोई अन्य तरीका आज़माएं जो सुरक्षित हो लेकिन फिर भी पढ़ने योग्य हो।

@deanveloper यह सच है कि यह प्रस्ताव (और उस मामले के लिए, किसी भी प्रस्ताव को एक ही चीज़ का प्रयास करने की कोशिश कर रहा है) स्रोत कोड से स्पष्ट रूप से दिखाई देने वाले return स्टेटमेंट को हटा देगा - यह प्रस्ताव का पूरा बिंदु है, है ना? if स्टेटमेंट और returns के बॉयलरप्लेट को हटाने के लिए जो सभी समान हैं। यदि आप return रखना चाहते हैं, तो try का उपयोग न करें।

हम return स्टेटमेंट्स (और panic 's) को तुरंत पहचानने के आदी हैं, क्योंकि इस तरह का नियंत्रण प्रवाह गो (और कई अन्य भाषाओं) में व्यक्त किया जाता है। यह बहुत दूर की कौड़ी नहीं है कि हम try को भी इसकी आदत पड़ने के बाद बदलते नियंत्रण प्रवाह के रूप में पहचान लेंगे, ठीक वैसे ही जैसे हम return के लिए करते हैं। मुझे इसमें कोई संदेह नहीं है कि अच्छा आईडीई समर्थन भी इसमें मदद करेगा।

मुझे दो चिंताएं हैं:

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

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

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

मुझे लगता है कि इन चिंताओं को एक चिमटा के साथ संबोधित किया जाएगा:

a, b, err := myFunc()
check(err, "calling myFunc on %v and %v", a, b)

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

यह try() के कई लाभों को बरकरार रखेगा:

• यह एक अंतर्निहित है
• यह मौजूदा नियंत्रण प्रवाह WRT को स्थगित करने के लिए अनुसरण करता है
• यह त्रुटियों में संदर्भ जोड़ने के मौजूदा अभ्यास के साथ अच्छी तरह से संरेखित है
• यह त्रुटि रैपिंग के लिए वर्तमान प्रस्तावों और पुस्तकालयों के साथ संरेखित करता है, जैसे errors.Wrap(err, "context message")
• यह एक क्लीन कॉल साइट में परिणत होता है: a, b, err := myFunc() लाइन पर कोई बॉयलरप्लेट नहीं है
• defer fmt.HandleError(&err, "msg") के साथ त्रुटियों का वर्णन करना अभी भी संभव है, लेकिन इसे प्रोत्साहित करने की आवश्यकता नहीं है।
• check का हस्ताक्षर थोड़ा आसान है, क्योंकि इसे लपेटने वाले फ़ंक्शन से मनमानी संख्या में तर्कों को वापस करने की आवश्यकता नहीं है।

@ s4n-gt इस लिंक के लिए धन्यवाद। मुझे इसकी जानकारी नहीं थी।

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

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

func main() {
  if err := newmain(); err != nil {
    println(err.Error())
    os.Exit(1)
  }
}

एक आखिरी आलोचना। वास्तव में प्रस्ताव की आलोचना नहीं है, बल्कि "फ़ंक्शन कंट्रोलिंग फ्लो" प्रतिवाद के लिए एक आम प्रतिक्रिया की आलोचना है।

"मुझे यह पसंद नहीं है कि एक फ़ंक्शन प्रवाह को नियंत्रित कर रहा है" की प्रतिक्रिया यह है कि " panic भी कार्यक्रम के प्रवाह को नियंत्रित करता है!"। हालांकि, कुछ कारण हैं कि panic के लिए ऐसा करना अधिक ठीक है जो $#$2 try #$ पर लागू नहीं होता है।

1. panic शुरुआती प्रोग्रामर के लिए अनुकूल है क्योंकि यह जो करता है वह सहज है, यह स्टैक को खोलना जारी रखता है। किसी को यह देखने की ज़रूरत नहीं है कि panic कैसे काम करता है यह समझने के लिए कि यह क्या करता है। शुरुआती प्रोग्रामर को recover के बारे में चिंता करने की भी आवश्यकता नहीं है, क्योंकि शुरुआती आमतौर पर पैनिक रिकवरी मैकेनिज्म का निर्माण नहीं कर रहे हैं, खासकर जब से वे पहली जगह में केवल घबराहट से बचने की तुलना में लगभग हमेशा कम अनुकूल होते हैं।

2. panic एक ऐसा नाम है जिसे देखना आसान है। यह चिंता लाता है, और इसकी आवश्यकता है। अगर कोई कोडबेस में panic देखता है, तो उन्हें तुरंत सोचना चाहिए कि कैसे घबराहट से बचने के लिए, भले ही यह मामूली हो।

3. अंतिम बिंदु से पीछे हटते हुए, panic को कॉल में नेस्ट नहीं किया जा सकता है, जिससे इसे देखना और भी आसान हो जाता है।

घबराहट के लिए कार्यक्रम के प्रवाह को नियंत्रित करना ठीक है क्योंकि यह पता लगाना बेहद आसान है, और यह सहज है कि यह क्या करता है।

try फ़ंक्शन इनमें से किसी भी बिंदु को संतुष्ट नहीं करता है।

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

2. try मेरी नजर में नहीं आता है, खासकर जब यह एक समारोह है। _विशेष रूप से_ जब सिंटैक्स हाइलाइटिंग इसे एक फ़ंक्शन के रूप में हाइलाइट करेगा। _ESPECIALLY_ जावा जैसी भाषा में विकसित होने के बाद, जहां try को अनावश्यक बॉयलरप्लेट के रूप में देखा जाता है (चेक किए गए अपवादों के कारण)।

3. मेरी पिछली टिप्पणी proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) में मेरे उदाहरण के अनुसार, try फ़ंक्शन कॉल के तर्क में उपयोग किया जा सकता है। इससे स्पॉट करना और भी मुश्किल हो जाता है।

मेरी आंखें try कार्यों को अनदेखा करती हैं, तब भी जब मैं उन्हें विशेष रूप से ढूंढ रहा हूं। मेरी आंखें उन्हें देख लेंगी, लेकिन तुरंत os.FindProcess या strconv.Atoi कॉल पर जाएं। try एक सशर्त वापसी है। नियंत्रण प्रवाह और रिटर्न दोनों गो में पेडस्टल पर रुके हुए हैं। किसी फ़ंक्शन के भीतर सभी नियंत्रण प्रवाह इंडेंट होते हैं, और सभी रिटर्न return से शुरू होते हैं। इन दोनों अवधारणाओं को एक साथ एक आसान-से-मिस फ़ंक्शन कॉल में मिलाकर बस थोड़ा सा लगता है।

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

@buchanae दिलचस्प। जैसा कि लिखा गया है, हालांकि, यह एक पैकेज से fmt-style फ़ॉर्मेटिंग को भाषा में ही स्थानांतरित करता है, जो कि कीड़े की एक कैन खोलता है।

जैसा कि लिखा गया है, हालांकि, यह एक पैकेज से fmt-style फ़ॉर्मेटिंग को भाषा में ही स्थानांतरित करता है, जो कि कीड़े की एक कैन खोलता है।

अच्छी बात। एक सरल उदाहरण:

a, b, err := myFunc()
check(err, "calling myFunc")

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

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

a, b, c, ... err := try(someFunctionCall())
if err != nil {
   return ..., err
}

इस तरह दिखने वाले बहुत सारे कोड हैं। और इस तरह दिखने वाले कोड के हर टुकड़े को अधिक त्रुटि प्रबंधन की आवश्यकता नहीं है। और जहां defer सही नहीं है, तब भी कोई if स्टेटमेंट का उपयोग कर सकता है।

मैं इस लाइन का पालन नहीं करता:

defer fmt.HandleErrorf(&err, “foobar”)

यह इनबाउंड त्रुटि को फर्श पर गिराता है, जो असामान्य है। क्या इसका मतलब इस तरह कुछ और इस्तेमाल किया जाना है?

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

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

मैं @buchanae द्वारा उठाए गए दो चिंताओं को साझा करता हूं, पुन: नामित रिटर्न और प्रासंगिक त्रुटियां।

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

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

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

मौजूदा कोड:

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations)
        if err != nil {
                return nil, err
        }
        t := &Thing{
                thingy: thingy,
        }
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil {
                return nil, err
        }
        t.initOtherThing()
        return t, nil
}

try के साथ:

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

पठनीयता का कोई नुकसान नहीं, सिवाय इसके कि यह कम स्पष्ट है कि newScanner विफल हो सकता है। लेकिन तब try वाली दुनिया में गो प्रोग्रामर इसकी उपस्थिति के प्रति अधिक संवेदनशील होंगे।

@josarian main एक error लौटाने के संबंध में: मुझे ऐसा लगता है कि आपका छोटा सहायक कार्य वही है जो समान प्रभाव प्राप्त करने के लिए आवश्यक है। मुझे यकीन नहीं है कि main के हस्ताक्षर को बदलना उचित है।

"फोबार" उदाहरण के बारे में: यह सिर्फ एक बुरा उदाहरण है। मुझे शायद इसे बदलना चाहिए। इसे लाने के लिए धन्यवाद।

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

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

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

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

@adg हां, try का उपयोग किया जा सकता है क्योंकि आप इसे अपने उदाहरण में उपयोग कर रहे हैं। मैंने आपकी टिप्पणियों को फिर से जाने दिया: नामित रिटर्न यथावत हैं।

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

try उन सभी प्रकार की चीजों को संभालने का प्रयास नहीं करता है जो लोग त्रुटियों के साथ करना चाहते हैं, केवल वही जिन्हें हम काफी सरल बनाने का एक व्यावहारिक तरीका खोज सकते हैं। मेरा मानना ​​है कि मेरा check उदाहरण उसी लाइन पर चलता है।

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

लेकिन, हो सकता है कि अन्य प्रस्ताव सभी त्रुटियों में स्टैक ट्रेस जोड़ दें? मैंने ट्रैक खो दिया है।

उदाहरण में @adg ने दिया, दो संभावित विफलताएं हैं लेकिन कोई संदर्भ नहीं है। यदि newScanner और RunMigrations स्वयं ऐसे संदेश प्रदान नहीं करते हैं जो आपको यह संकेत देते हैं कि कौन सा गलत हुआ, तो आप अनुमान लगाना छोड़ देते हैं।

उदाहरण में @adg ने दिया, दो संभावित विफलताएं हैं लेकिन कोई संदर्भ नहीं है। यदि newScanner और RunMigrations स्वयं संदेश प्रदान नहीं करते हैं जो आपको यह संकेत देते हैं कि कौन सा गलत हुआ, तो आप अनुमान लगा रहे हैं।

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

मैं चिंता को @deanveloper और अन्य के रूप में साझा करता हूं कि यह डिबगिंग को कठिन बना सकता है। यह सच है कि हम इसका उपयोग नहीं करना चुन सकते हैं, लेकिन तृतीय-पक्ष निर्भरता की शैलियाँ हमारे नियंत्रण में नहीं हैं।
यदि कम दोहराव if err := ... { return err } प्राथमिक बिंदु है, तो मुझे आश्चर्य है कि क्या "सशर्त वापसी" पर्याप्त होगी, जैसे https://github.com/golang/go/issues/27794 प्रस्तावित।

        return nil, err if f, err := os.Open(...)
        return nil, err if _, err := os.Write(...)

मुझे लगता है कि ? try से बेहतर फिट होगा, और त्रुटि के लिए हमेशा defer का पीछा करना भी मुश्किल होगा।

यह हमेशा के लिए try/catch का उपयोग करके अपवाद होने के द्वार भी बंद कर देता है।

यह हमेशा के लिए प्रयास/पकड़ का उपयोग करके अपवाद होने के द्वार भी बंद कर देता है।

मैं इसके साथ _more_ ठीक हूं।

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

जैसा कि @griesemer कहते हैं:

फिर, यह प्रस्ताव सभी त्रुटि प्रबंधन स्थितियों को हल करने का प्रयास नहीं करता है। मुझे संदेह है कि ज्यादातर मामलों में कोड के लिए प्रयास करें जो अब मूल रूप से इस तरह दिखता है:
ए, बी, सी, ... गलती: = कोशिश करें (कुछ फ़ंक्शन कॉल ())
अगर गलती!= शून्य {
वापसी ..., त्रुटि
}
इस तरह दिखने वाले बहुत सारे कोड हैं। और इस तरह दिखने वाले कोड के हर टुकड़े को अधिक त्रुटि प्रबंधन की आवश्यकता नहीं है। और जहां defer सही नहीं है, तब भी कोई if स्टेटमेंट का उपयोग कर सकता है।

हां, लेकिन अच्छा नहीं होना चाहिए, मुहावरेदार कोड हमेशा अपनी त्रुटियों को लपेटते/सजाते हैं? मेरा मानना ​​​​है कि इसलिए हम stdlib में संदर्भ/रैप त्रुटियों को जोड़ने के लिए परिष्कृत त्रुटि प्रबंधन तंत्र पेश कर रहे हैं। जैसा कि मैंने देखा, यह प्रस्ताव केवल सबसे बुनियादी उपयोग के मामले पर विचार करता है।

इसके अलावा, यह प्रस्ताव केवल एक _single स्थान_ पर कई संभावित त्रुटि वापसी साइटों को लपेटने/सजाने के मामले को संबोधित करता है, एक स्थगित कॉल के साथ नामित पैरामीटर का उपयोग करके।

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

यह मेरे पास एक वास्तविक कोड का एक उदाहरण है -

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    if err != nil {
        return err
    }
    var res int64
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table: %w", err)
    }

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table2: %w", err)
    }
    return tx.Commit()
}

प्रस्ताव के अनुसार:

यदि त्रुटि वृद्धि या रैपिंग वांछित है, तो दो दृष्टिकोण हैं: कोशिश की गई और सही अगर कथन के साथ चिपके रहें, या वैकल्पिक रूप से, एक त्रुटि हैंडलर को एक स्थगित कथन के साथ "घोषित" करें:

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

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

try() अवधारणा में चेक/हैंडल से check की सभी समस्याएं हैं:

1. यह गो की तरह नहीं पढ़ता है। लोग असाइनमेंट सिंटैक्स चाहते हैं, बाद में शून्य परीक्षण के बिना, जैसा कि गो जैसा दिखता है। जाँच/संभालने के लिए तेरह अलग-अलग प्रतिक्रियाओं ने यह सुझाव दिया; यहां _आवर्ती थीम_ देखें:
   https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

   f, #      := os.Open(...) // return on error
   f, #panic := os.Open(...) // panic on error
   f, #hname := os.Open(...) // invoke named handler on error
   // # is any available symbol or unambiguous pair
   

2. फ़ंक्शन कॉल की नेस्टिंग जो त्रुटियों को वापस करती है, संचालन के क्रम को अस्पष्ट करती है, और डिबगिंग में बाधा डालती है। मामलों की स्थिति जब कोई त्रुटि होती है, और इसलिए कॉल अनुक्रम स्पष्ट होना चाहिए, लेकिन यहां यह नहीं है:
   try(step4(try(step1()), try(step3(try(step2())))))
   अब याद रखें कि भाषा मना करती है:
   f(t ? a : b) और f(a++)

3. संदर्भ के बिना त्रुटियों को वापस करना तुच्छ होगा। जांच/संभाल का एक प्रमुख तर्क संदर्भीकरण को प्रोत्साहित करना था।

4. यह error टाइप करने और अंतिम वापसी मूल्य से जुड़ा हुआ है। अगर हमें असाधारण स्थिति के लिए अन्य वापसी मूल्यों/प्रकारों का निरीक्षण करने की आवश्यकता है, तो हम वापस आ गए हैं: if errno := f(); errno != 0 { ... }

5. यह कई रास्ते प्रदान नहीं करता है। कोड जो स्टोरेज या नेटवर्किंग एपीआई को कॉल करता है, गलत इनपुट या अनपेक्षित आंतरिक स्थिति के कारण ऐसी त्रुटियों को अलग तरीके से हैंडल करता है। मेरा कोड इनमें से एक को return err से कहीं अधिक बार करता है:

   • लॉग। घातक ()
   • पैनिक () उन त्रुटियों के लिए जो कभी उत्पन्न नहीं होनी चाहिए
   • एक संदेश लॉग करें और पुनः प्रयास करें

@gopherbot Go2, LanguageChange जोड़ें

कैसे केवल ? rust की तरह परिणाम को खोलने के लिए करें

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

func doSomething() (int, %error) {
  f := try(foo())
  ...
}

• हम try() का उपयोग नहीं कर सकते हैं यदि doSomething में %error रिटर्न वैल्यू में नहीं है।
• हम कोशिश () का उपयोग नहीं कर सकते हैं यदि फू () में अंतिम रिटर्न वैल्यू में त्रुटि नहीं है।

मौजूदा सिंटैक्स में नई आवश्यकताओं/सुविधाओं को जोड़ना कठिन है।

ईमानदार होने के लिए, मुझे लगता है कि foo() में% त्रुटि भी होनी चाहिए।

1 और नियम जोड़ें

• % त्रुटि किसी फ़ंक्शन की वापसी मान सूची में केवल एक हो सकती है।

विस्तृत डिज़ाइन दस्तावेज़ में मैंने देखा कि पहले के पुनरावृत्ति में यह सुझाव दिया गया था कि एक त्रुटि हैंडलर को try बिल्टिन फ़ंक्शन में पास किया जाए। इस कदर:

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

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

या इससे भी बेहतर, इस तरह:

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

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

दूसरे, मुझे इस बात से कोई आपत्ति नहीं है कि इसमें निर्मित एक फ़ंक्शन को वापस करने का कारण बन सकता है, लेकिन, थोड़ा सा बाइक करने के लिए, 'कोशिश' नाम यह सुझाव देने के लिए बहुत छोटा है कि यह वापसी का कारण बन सकता है। तो एक लंबा नाम, जैसे attempt मुझे बेहतर लगता है।

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

हैकर समाचार में कुछ बिंदु है: try एक सामान्य कार्य की तरह व्यवहार नहीं करता है (यह वापस आ सकता है) इसलिए इसे फ़ंक्शन-जैसे सिंटैक्स देना अच्छा नहीं है। एक return या defer सिंटैक्स अधिक उपयुक्त होगा:

func CopyFile(src, dst string) (err error) {
        r := try os.Open(src)
        defer r.Close()

        w := try os.Create(dst)
        defer func() {
                w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try io.Copy(w, r)
        try w.Close()
        return nil
}

@sheerun इसका सामान्य प्रतिवाद यह है कि panic भी एक नियंत्रण-प्रवाह परिवर्तनकारी अंतर्निहित कार्य है। मैं व्यक्तिगत रूप से इससे असहमत हूं, हालांकि यह सही है।

1. ऊपर दिए गए @deanveloper के साथ-साथ दूसरों की समान टिप्पणियों को प्रतिध्वनित करते हुए, मुझे बहुत डर है कि हम एक नया, कुछ हद तक सूक्ष्म जोड़ने की लागत को कम करके आंक रहे हैं, और विशेष रूप से जब अन्य फ़ंक्शन कॉल में इनलाइन किया जाता है-आसानी से अनदेखा कीवर्ड जो कॉल स्टैक नियंत्रण का प्रबंधन करता है बहे। panic(...) इस नियम का एक अपेक्षाकृत स्पष्ट अपवाद है (जिसका इरादा नहीं है) कि return किसी फ़ंक्शन से बाहर निकलने का एकमात्र तरीका है। मुझे नहीं लगता कि हमें इसके अस्तित्व को एक तिहाई जोड़ने के औचित्य के रूप में इस्तेमाल करना चाहिए।
2. यह प्रस्ताव एक गैर-लिपटे त्रुटि को डिफ़ॉल्ट व्यवहार के रूप में लौटाने के लिए कैननाइज़ करेगा, और अतिरिक्त समारोह के साथ रैपिंग त्रुटियों को उस चीज़ के रूप में छोड़ देगा, जिसमें आपको ऑप्ट-इन करना होगा। लेकिन, मेरे अनुभव में, यह अच्छे अभ्यास के ठीक पीछे है। मुझे आशा है कि इस स्थान में एक प्रस्ताव त्रुटि साइट पर त्रुटियों के लिए प्रासंगिक जानकारी जोड़ने के लिए आसान, या कम से कम अधिक कठिन नहीं बना देगा।

हो सकता है कि हम इस शब्दार्थ के साथ tryf जैसे वैकल्पिक वृद्धि समारोह के साथ एक संस्करण जोड़ सकते हैं:

func tryf(t1 T1, t1 T2, … tn Tn, te error, fn func(error) error) (T1, T2, … Tn)

इसका अनुवाद करता है

x1, x2, … xn = tryf(f(), func(err error) { return fmt.Errorf("foobar: %q", err) })

इस मामले में

t1, … tn, te := f()
if te != nil {
    if fn != nil {
        te = fn(te)
    }
    err = te
    return
}

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

मुझे चिंता है कि try पारंपरिक त्रुटि प्रबंधन को प्रतिस्थापित कर देगा, और यह कि परिणाम के रूप में व्याख्या त्रुटि पथ को और अधिक कठिन बना देगा।

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

a, b, err := doWork()
if err != nil {
  updateCounters()
  writeLogs()
  return err
}

टूलिंग (fmt, lint, आदि) द्वारा लागू सामान्य मुहावरों के साथ गो एक अत्यंत सामाजिक भाषा है। कृपया इस विचार के सामाजिक प्रभाव को ध्यान में रखें - हर जगह इसका उपयोग करने की प्रवृत्ति होगी।

@politician , क्षमा करें, लेकिन आप जिस शब्द की तलाश कर रहे हैं वह _social_ नहीं बल्कि _opinionated_ है। गो एक ओपिनेटेड प्रोग्रामिंग लैंग्वेज है। बाकी के लिए मैं अधिकतर सहमत हूं कि आपको क्या मिल रहा है।

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

@politician स्पष्टीकरण के लिए धन्यवाद, मैं इसे इस तरह समझ नहीं पाया था। मैं निश्चित रूप से सहमत हो सकता हूं कि हमें नाटक से बचने की कोशिश करनी चाहिए।

मैं इसे लेकर भ्रमित हूं।

ब्लॉग से: त्रुटियाँ मान हैं , मेरे दृष्टिकोण से, इसे इस तरह से डिज़ाइन किया गया है कि इसे अनदेखा न किया जाए।

और मुझे विश्वास है कि रोप पाइक ने क्या कहा, "मूल्यों को क्रमादेशित किया जा सकता है, और चूंकि त्रुटियां मूल्य हैं, इसलिए त्रुटियों को क्रमादेशित किया जा सकता है।"

हमें error को exception $ के रूप में नहीं मानना ​​​​चाहिए, यह न केवल सोचने के लिए बल्कि कोडिंग के लिए भी जटिलता आयात करने जैसा है यदि हम ऐसा करते हैं।

"अपनी त्रुटि प्रबंधन को आसान बनाने के लिए भाषा का प्रयोग करें।" — रोब पाइक

और भी बहुत कुछ, हम इस स्लाइड की समीक्षा कर सकते हैं

एक स्थिति जहां मुझे if के माध्यम से त्रुटि जांच मिलती है, विशेष रूप से अजीब है जब फाइलें बंद करना (उदाहरण के लिए एनएफएस पर)। मुझे लगता है, वर्तमान में हम निम्नलिखित लिखने के लिए हैं, यदि .Close() से त्रुटि रिटर्न संभव है?

r, err := os.Open(src)
if err != nil {
    return err
}
defer func() {
    // maybe check whether a previous error occured?
    return r.Close()
}()

क्या defer try(r.Close()) ऐसी त्रुटियों से निपटने के किसी तरीके के लिए प्रबंधनीय वाक्यविन्यास रखने का एक अच्छा तरीका हो सकता है? कम से कम, प्रस्ताव में CopyFile() उदाहरण को किसी तरह से समायोजित करना समझदारी होगी, ताकि r.Close() और w.Close() की त्रुटियों को नज़रअंदाज़ न किया जा सके।

@seehuhn आपका उदाहरण संकलित नहीं होगा क्योंकि स्थगित फ़ंक्शन में रिटर्न प्रकार नहीं है।

func doWork() (err error) {
  r, err := os.Open(src)
  if err != nil {
    return err
  }
  defer func() {
    err = r.Close()  // overwrite the return value
  }()
}

आपकी अपेक्षा के अनुरूप काम करेगा। कुंजी नामित वापसी मूल्य है।

मुझे प्रस्ताव पसंद है लेकिन मुझे लगता है कि @seehuhn के उदाहरण को भी संबोधित किया जाना चाहिए:

defer try(w.Close())

त्रुटि को बंद करें() से केवल तभी लौटाएगा जब त्रुटि पहले से सेट नहीं थी।
यह पैटर्न इतनी बार प्रयोग किया जाता है ...

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

पहली चीज जिसके बारे में मैंने सोचा था कि fmt.HandleErrorf को tryf फ़ंक्शन के साथ प्रतिस्थापित करना था, जो अतिरिक्त संदर्भ के साथ त्रुटि को उपसर्ग करता है।

func tryf(t1 T1, t1 T2, … tn Tn, te error, ts string) (T1, T2, … Tn)

उदाहरण के लिए (मेरे पास एक वास्तविक कोड से):

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil {
        return nil, errors.WithMessage(err, "load config dir")
    }
    b := bytes.NewBuffer(nil)
    if err = templates.ExecuteTemplate(b, "main", c); err != nil {
        return nil, errors.WithMessage(err, "execute main template")
    }
    buf, err := format.Source(b.Bytes())
    if err != nil {
        return nil, errors.WithMessage(err, "format main template")
    }
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    if err := ioutil.WriteFile(target, buf, 0644); err != nil {
        return nil, errors.WithMessagef(err, "write file %s", target)
    }
    // ...
}

कुछ इस तरह बदला जा सकता है:

func (c *Config) Build() error {
    pkgPath := tryf(c.load(), "load config dir")
    b := bytes.NewBuffer(nil)
    tryf(emplates.ExecuteTemplate(b, "main", c), "execute main template")
    buf := tryf(format.Source(b.Bytes()), "format main template")
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    tryf(ioutil.WriteFile(target, buf, 0644), fmt.Sprintf("write file %s", target))
    // ...
}

या, अगर मैं @agnivade का उदाहरण लेता हूं:

func (p *pgStore) DoWork() (err error) {
    tx := tryf(p.handle.Begin(), "begin transaction")
        defer func() {
        if err != nil {
            tx.Rollback()
        }
    }()
    var res int64
    tryf(tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res), "insert table")
    _, = tryf(tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res), "insert table2")
    return tryf(tx.Commit(), "commit transaction")
}

हालांकि, @josarian ने एक अच्छा मुद्दा उठाया जो मुझे इस समाधान पर संकोच करता है:

जैसा कि लिखा गया है, हालांकि, यह एक पैकेज से fmt-style फ़ॉर्मेटिंग को भाषा में ही स्थानांतरित करता है, जो कि कीड़े की एक कैन खोलता है।

मैं इस प्रस्ताव के साथ पूरी तरह से सहमत हूं और कई उदाहरणों में इसके लाभ देख सकता हूं।

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

मेरे लिए, मैं बिल्टिन को pass कहलाना पसंद करूंगा। मुझे लगता है कि यह जो हो रहा है उसका बेहतर प्रतिनिधित्व देता है। आखिरकार आप त्रुटि को संभाल नहीं रहे हैं - बल्कि इसे कॉलर द्वारा नियंत्रित करने के लिए वापस भेज रहे हैं। try यह आभास देता है कि त्रुटि को संभाल लिया गया है।

यह मेरे लिए एक अंगूठा है, मुख्यतः क्योंकि जिस समस्या का समाधान करना है ("बॉयलरप्लेट यदि कथन आमतौर पर त्रुटि प्रबंधन से जुड़े हैं") बस मेरे लिए कोई समस्या नहीं है। यदि सभी त्रुटि जांच केवल if err != nil { return err } तो मैं उसके लिए वाक्यात्मक चीनी जोड़ने में कुछ मूल्य देख सकता था (हालांकि गो झुकाव से अपेक्षाकृत चीनी मुक्त भाषा है)।

वास्तव में, गैर-शून्य त्रुटि की स्थिति में मैं जो करना चाहता हूं वह एक स्थिति से दूसरी स्थिति में काफी भिन्न होता है। शायद मुझे t.Fatal(err) चाहिए। शायद मैं एक सजाने वाला संदेश जोड़ना चाहता हूं return fmt.Sprintf("oh no: %v", err) । हो सकता है कि मैं सिर्फ त्रुटि लॉग करूं और जारी रखूं। हो सकता है कि मैंने अपने SafeWriter ऑब्जेक्ट पर एक त्रुटि ध्वज सेट किया हो और संचालन के कुछ अनुक्रम के अंत में ध्वज की जाँच करना जारी रखा हो। शायद मुझे कुछ और कार्रवाई करने की ज़रूरत है। इनमें से किसी को भी try के साथ स्वचालित नहीं किया जा सकता है। तो यदि try के लिए तर्क यह है कि यह सभी if err != nil ब्लॉक को समाप्त कर देगा, तो यह तर्क खड़ा नहीं होता है।

क्या यह उनमें से _some_ को खत्म कर देगा? ज़रूर। क्या यह मेरे लिए आकर्षक प्रस्ताव है? मेह। मैं वास्तव में चिंतित नहीं हूं। मेरे लिए, if err != nil घुंघराले ब्रेसिज़, या defer की तरह, गो का केवल एक हिस्सा है। मैं समझता हूं कि यह उन लोगों के लिए वर्बोज़ और दोहराव वाला लगता है जो गो के लिए नए हैं, लेकिन जो लोग गो के लिए नए हैं, वे कई कारणों से भाषा में नाटकीय परिवर्तन करने के लिए सबसे अच्छी स्थिति में नहीं हैं।

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

@peterbourgon और @deanveloper को प्रतिध्वनित करने के लिए, गो के बारे में मेरी पसंदीदा चीजों में से एक यह है कि कोड प्रवाह स्पष्ट है और पैनिक () को मानक प्रवाह नियंत्रण तंत्र की तरह नहीं माना जाता है जिस तरह से यह पायथन में है।

दहशत पर बहस के संबंध में, घबराहट () लगभग हमेशा अपने आप में एक पंक्ति में प्रकट होती है क्योंकि इसका कोई मूल्य नहीं है। आप fmt.Println(panic("oops")) नहीं कर सकते। यह इसकी दृश्यता को जबरदस्त रूप से बढ़ाता है और लोगों की तुलना में इसे try() से बहुत कम तुलनीय बनाता है।

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

प्रस्ताव में उदाहरणों में से एक मेरे लिए समस्या का समाधान करता है:

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

नियंत्रण प्रवाह वास्तव में कम स्पष्ट और बहुत अस्पष्ट हो जाता है।

यह रॉब पाइक के प्रारंभिक इरादे के खिलाफ भी है कि सभी त्रुटियों को स्पष्ट रूप से संभालने की आवश्यकता है।

जबकि इस पर प्रतिक्रिया हो सकती है "फिर इसका उपयोग न करें", समस्या यह है - अन्य पुस्तकालय इसका उपयोग करेंगे, और उन्हें डिबग करना, उन्हें पढ़ना और उनका उपयोग करना, अधिक समस्याग्रस्त हो जाता है। यह मेरी कंपनी को गो 2 को कभी नहीं अपनाने के लिए प्रेरित करेगा, और केवल उन पुस्तकालयों का उपयोग करना शुरू करेगा जो try का उपयोग नहीं करते हैं। अगर मैं इसके साथ अकेला नहीं हूं, तो इससे एक-ला अजगर 2/3 विभाजन हो सकता है।

साथ ही, try का नामकरण स्वचालित रूप से यह संकेत देगा कि अंततः catch सिंटैक्स में दिखाई देगा, और हम जावा होने पर वापस आ जाएंगे।

इसलिए, इस सब के कारण, मैं इस प्रस्ताव के _दृढ़ता से_विरोध करता हूं।

मुझे try नाम पसंद नहीं है। इसका तात्पर्य विफलता के उच्च जोखिम के साथ कुछ करने पर एक _attempt_ है (मेरे पास _try_ के खिलाफ सांस्कृतिक पूर्वाग्रह हो सकता है क्योंकि मैं मूल अंग्रेजी स्पीकर नहीं हूं), जबकि इसके बजाय try का उपयोग दुर्लभ विफलताओं की उम्मीद के मामले में किया जाएगा। (त्रुटि प्रबंधन की वाचालता को कम करने की इच्छा के लिए प्रेरणा) और आशावादी हैं। इसके अलावा इस प्रस्ताव में try वास्तव में इसे जल्दी वापस करने में त्रुटि _catches_ करता है। मुझे @HiImJC का pass सुझाव पसंद है।

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

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

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

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

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

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

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

एक अन्य समाधान उस साइट से लौटाए जा सकने वाले त्रुटि प्रकारों को परिभाषित/श्वेतसूचीबद्ध करने के लिए try के लिए वैकल्पिक दूसरा तर्क रखने के (छोड़े गए) विचार का पुनरुत्पादन करना होगा। यह थोड़ा परेशानी भरा है क्योंकि हमारे पास "त्रुटि प्रकार" को परिभाषित करने के दो अलग-अलग तरीके हैं, या तो मूल्य ( io.EOF आदि) या प्रकार ( *os.PathError , *exec.ExitError )। त्रुटि प्रकारों को निर्दिष्ट करना आसान है जो किसी फ़ंक्शन के लिए तर्क के रूप में मान हैं, लेकिन प्रकारों को निर्दिष्ट करना कठिन है। सुनिश्चित नहीं है कि इसे कैसे संभालना है, लेकिन विचार को वहां फेंकना।

त्रुटि के मूल्यांकन में देरी से @josarian ने जिस समस्या की ओर इशारा किया है, उससे बचा जा सकता है:

defer func() { fmt.HandleErrorf(&err, "oops: %v", err) }()

बहुत अच्छा नहीं लग रहा है, लेकिन यह काम करना चाहिए। हालांकि मैं पसंद करूंगा यदि इसे त्रुटि पॉइंटर्स के लिए एक नया स्वरूपण क्रिया/ध्वज जोड़कर संबोधित किया जा सकता है, या शायद सामान्य रूप से पॉइंटर्स के लिए, जो सादे %v के साथ संदर्भित मान को प्रिंट करता है। उदाहरण के उद्देश्य के लिए, आइए इसे %*v कहते हैं:

defer fmt.HandleErrorf(&err, "oops: %*v", &err)

एक तरफ रोड़ा, मुझे लगता है कि यह प्रस्ताव आशाजनक लग रहा है, लेकिन त्रुटियों के संदर्भ को जोड़ने के एर्गोनॉमिक्स को जांच में रखना महत्वपूर्ण लगता है।

संपादित करें:

एक अन्य तरीका त्रुटि सूचक को उस संरचना में लपेटना है जो Stringer लागू करता है:

type wraperr struct{ err *error }
func (w wraperr) String() string { return (*w.err).Error() }

...

defer handleErrorf(&err, "oops: %v", wraperr{&err})

मेरे दृष्टिकोण से कुछ बातें। हम कोड की कुछ पंक्तियों को सहेजने के लिए इतने चिंतित क्यों हैं? मैं इसे उसी तर्ज पर मानता हूं जैसे छोटे कार्यों को हानिकारक माना जाता है ।

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

जैसा कि कहा गया है प्रस्ताव में कई अस्पष्ट व्यवहार भी हैं, इसलिए यह पहले से ही एक _explicit_ अतिरिक्त ~ 3 लाइनों की तुलना में समस्याग्रस्त है जो अधिक स्पष्ट हैं।

वर्तमान में हम घर में आस्थगित पैटर्न का संयम से उपयोग करते हैं। यहां एक लेख है, जिसे लिखते समय समान रूप से मिश्रित प्रतिक्रिया मिली थी - https://bet365techblog.com/better-error-handling-in-go

हालांकि, इसका हमारा उपयोग check / handle प्रस्ताव की प्रगति की प्रत्याशा में था।

अधिक संक्षिप्त में त्रुटि प्रबंधन करने के लिए चेक/हैंडल एक अधिक व्यापक दृष्टिकोण था। इसके handle ब्लॉक ने उसी फंक्शन स्कोप को बरकरार रखा है, जिसमें इसे परिभाषित किया गया था, जबकि कोई भी defer स्टेटमेंट ओवरहेड के एक राशि के साथ नए संदर्भ हैं। यह गो के मुहावरों को ध्यान में रखते हुए अधिक प्रतीत होता है, यदि आप चाहते हैं कि "ऐसा होने पर त्रुटि वापस करें" का व्यवहार आप स्पष्ट रूप से handle { return err } के रूप में घोषित कर सकते हैं।

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

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

यदि डिफर-आधारित त्रुटि प्रबंधन ए थिंग होने जा रहा है, तो कुछ इस तरह से शायद त्रुटि पैकेज में जोड़ा जाना चाहिए:

        f := try(os.Create(filename))
        defer errors.Deferred(&err, f.Close)

आस्थगित क्लोज स्टेटमेंट की त्रुटियों को अनदेखा करना एक बहुत ही सामान्य मुद्दा है। इसकी सहायता के लिए एक मानक उपकरण होना चाहिए।

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

1. https://ziglang.org/documentation/master/#try

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

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

मुझे लगता है कि यह काफी दूर की कौड़ी है। gofmt'ed कोड में, रिटर्न हमेशा /^\t*return / से मेल खाता है - यह बिना किसी सहायता के आंखों से देखने के लिए एक बहुत ही छोटा पैटर्न है। दूसरी ओर, try , कोड में कहीं भी हो सकता है, फ़ंक्शन कॉल में मनमाने ढंग से गहरा घोंसला। प्रशिक्षण की कोई भी राशि हमें टूल सहायता के बिना किसी फ़ंक्शन में सभी नियंत्रण प्रवाह को तुरंत पहचानने में सक्षम नहीं बनाती है।

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

भाषा की विशेषता को अपने आप समझना आसान होना चाहिए, संपादक के समर्थन पर निर्भर नहीं होना चाहिए।

@kungfusheep मुझे वह लेख पसंद है। अकेले डिफर में लपेटने का ख्याल रखना पहले से ही try के बिना पठनीयता को काफी बढ़ा देता है।

मैं उस शिविर में हूं जो गो में त्रुटियां महसूस नहीं करता वास्तव में एक समस्या है। फिर भी, if err != nil { return err } कुछ कार्यों पर काफी हद तक हो सकता है। मैंने ऐसे कार्य लिखे हैं जिन्हें लगभग हर कथन के बाद त्रुटि जांच की आवश्यकता होती है और किसी को भी रैप और रिटर्न के अलावा किसी विशेष हैंडलिंग की आवश्यकता नहीं होती है। कभी-कभी कोई चतुर बफ़र संरचना नहीं होती है जो चीजों को अच्छा बनाने वाली होती है। कभी-कभी यह एक के बाद एक अलग महत्वपूर्ण कदम होता है और कुछ गलत होने पर आपको बस शॉर्ट सर्किट करने की आवश्यकता होती है।

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

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

यह एक विशेष आवरण मैक्रो जैसा दिखता है।

@dominikh try हमेशा /try\(/ से मेल खाता है इसलिए मुझे नहीं पता कि आपकी बात वास्तव में क्या है। यह उतना ही खोजने योग्य है जितना मैंने कभी सुना है और प्रत्येक संपादक में एक खोज सुविधा है।

@qrpnxz मुझे लगता है कि वह जिस बिंदु को बनाने की कोशिश कर रहा था वह यह नहीं है कि आप इसे प्रोग्रामिक रूप से नहीं खोज सकते हैं, लेकिन यह आपकी आंखों से खोजना मुश्किल है। रेगेक्सपी केवल एक सादृश्य था, जिसमें /^\t* पर जोर दिया गया था, यह दर्शाता है कि सभी रिटर्न स्पष्ट रूप से एक पंक्ति की शुरुआत में (अग्रणी व्हाइटस्पेस को अनदेखा करके) खड़े हो जाते हैं।

इसके बारे में अधिक सोचते हुए, कुछ सामान्य सहायक कार्य होने चाहिए। शायद उन्हें "स्थगित" नामक पैकेज में होना चाहिए।

रिटर्न के नामकरण से बचने के लिए प्रारूप के साथ check के प्रस्ताव को संबोधित करते हुए, आप इसे केवल उस फ़ंक्शन के साथ कर सकते हैं जो शून्य की जांच करता है, जैसे

func Format(err error, message string, args ...interface{}) error {
    if err == nil {
        return nil
    }
    return fmt.Errorf(...)
}

इसका उपयोग नामित रिटर्न के बिना किया जा सकता है:

func foo(s string) (int, error) {
    n, err := strconv.Atoi(s)
    try(deferred.Format(err, "bad string %q", s))
    return n, nil
}

प्रस्तावित fmt.HandleError को इसके बजाय आस्थगित पैकेज में रखा जा सकता है और मेरी त्रुटियां। डिफर हेल्पर func को deferred.Exec कहा जा सकता है और केवल त्रुटि गैर-शून्य होने पर प्रक्रियाओं को निष्पादित करने के लिए एक सशर्त निष्पादन हो सकता है।

इसे एक साथ रखकर, आपको कुछ मिलता है

func CopyFile(src, dst string) (err error) {
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r := try(os.Open(src))
    defer deferred.Exec(&err, r.Close)

    w := try(os.Create(dst))
    defer deferred.Exec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    try(io.Copy(w, r))

    return nil
}

एक और उदाहरण:

func (p *pgStore) DoWork() (err error) {
    tx := try(p.handle.Begin())

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(deferred.Format(err, "insert table")

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(deferred.Format(err, "insert table2"))

    return tx.Commit()
}

यह प्रस्ताव हमें हर जगह if err != nil होने से लेकर हर जगह try होने तक ले जाता है। यह प्रस्तावित समस्या को स्थानांतरित करता है और इसे हल नहीं करता है।

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

इसके अलावा, मैं तर्क दूंगा कि if err != nil वास्तव में try से अधिक पठनीय है क्योंकि यह व्यापार तर्क भाषा की रेखा को अव्यवस्थित नहीं करता है, बल्कि इसके ठीक नीचे बैठता है:

file := try(os.OpenFile("thing")) // less readable than, 

file, err := os.OpenFile("thing")
if err != nil {

}

और अगर गो को अपनी त्रुटि से निपटने में अधिक जादुई होना था, तो क्यों न इसे पूरी तरह से अपना लिया जाए। उदाहरण के लिए, यदि उपयोगकर्ता कोई त्रुटि निर्दिष्ट नहीं करता है, तो गो अंतर्निहित try को अंतर्निहित रूप से कॉल कर सकता है। उदाहरण के लिए:

func getString() (string, error) { ... }

func caller() {
  defer func() {
    if err != nil { ... } // whether `err` must be defined or not is not shown in this example. 
  }

  // would call try internally, because a user is not 
  // assigning an error value. Also, it can add a compile error
  // for "defined and not used err value" if the user does not 
  // handle the error. 
  str := getString()
}

मेरे लिए, यह वास्तव में जादू और संभावित पठनीयता की कीमत पर अतिरेक समस्या को पूरा करेगा।

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

उदाहरण के लिए, VSCode में iferr नामक एक स्निपेट होता है यदि आप इसे टाइप करते हैं और एंटर दबाते हैं, तो यह एक पूर्ण त्रुटि प्रबंधन कथन तक फैल जाता है ... इसलिए, इसे लिखना मुझे कभी भी थकाऊ नहीं लगता है, और बाद में पढ़ना बेहतर है .

@ जोशेरियन

हालांकि यह "एक मामूली पुस्तकालय परिवर्तन" नहीं होगा, हम func main() त्रुटि को भी स्वीकार करने पर विचार कर सकते हैं।

इसके साथ मुद्दा यह है कि सभी प्लेटफार्मों में इसका अर्थ स्पष्ट नहीं है। आपका पुनर्लेखन पूर्ण ऑपरेटिंग सिस्टम पर चलने वाले "पारंपरिक" गो प्रोग्राम में अच्छी तरह से काम करता है - लेकिन जैसे ही आप माइक्रोकंट्रोलर-फर्मवेयर या यहां तक ​​​​कि सिर्फ WebAssembly लिखते हैं, यह सुपर स्पष्ट नहीं है कि os.Exit(1) का क्या अर्थ होगा। वर्तमान में, os.Exit एक लाइब्रेरी-कॉल है, इसलिए इसे प्रदान न करने के लिए गो कार्यान्वयन निःशुल्क हैं। हालांकि main का आकार भाषा की चिंता का विषय है।

प्रस्ताव के बारे में एक प्रश्न जिसका उत्तर शायद "नहीं" द्वारा दिया गया है: try विविध तर्कों के साथ कैसे इंटरैक्ट करता है? यह एक variadic (ish) फ़ंक्शन का पहला मामला है जिसमें अंतिम तर्क में इसका variadic-nes नहीं है। क्या इसकी अनुमति है:

var e []error
try(e...)

एक तरफ छोड़कर आप कभी ऐसा क्यों करेंगे। मुझे संदेह है कि उत्तर "नहीं" है (अन्यथा अनुवर्ती है "क्या होगा यदि विस्तारित स्लाइस की लंबाई 0 है)। बस इसे ऊपर लाना ताकि अंततः कल्पना को फिर से तैयार करते समय इसे ध्यान में रखा जा सके।

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

मुझे इसके साथ दो समस्याएं दिखाई देती हैं:

1. यह फ़ंक्शन के अंदर नेस्टेड बहुत सारे कोड डालता है। यह आपके दिमाग में कोड को पार्स करने की कोशिश में बहुत अधिक अतिरिक्त संज्ञानात्मक भार जोड़ता है।

1. यह हमें वह स्थान देता है जहां कोड एक बयान के बीच से बाहर निकल सकता है।

नंबर 2 मुझे लगता है कि बहुत बुरा है। यहां सभी उदाहरण सरल कॉल हैं जो एक त्रुटि लौटाते हैं, लेकिन जो बहुत अधिक कपटी है वह यह है:

func doit(abc string) error {
    a := fmt.Sprintf("value of something: %s\n", try(getValue(abc)))
    log.Println(a)
    return nil
}

यह कोड उस स्प्रिंटफ के बीच में बाहर निकल सकता है, और उस तथ्य को याद करना बहुत आसान होगा।

मेरा वोट नहीं है। इससे गो कोड बेहतर नहीं होगा। इसे पढ़ना आसान नहीं होगा। यह इसे और अधिक मजबूत नहीं बनाएगा।

मैंने इसे पहले कहा है, और यह प्रस्ताव इसका उदाहरण देता है - मुझे ऐसा लगता है कि गो के बारे में 90% शिकायतें हैं "मैं एक बयान या लूप लिखना नहीं चाहता"। यह कुछ बहुत ही सरल if कथनों को हटा देता है, लेकिन संज्ञानात्मक भार जोड़ता है और किसी फ़ंक्शन के लिए निकास बिंदुओं को याद करना आसान बनाता है।

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

func main() {
    f := try(os.Open("foo.txt"))
    defer f.Close()
}

मुझे यकीन नहीं है कि मुख्य रूप से घबराहट की कोशिश करना स्वीकार्य होगा।

इसके अतिरिक्त यह परीक्षणों में विशेष रूप से उपयोगी नहीं होगा ( func TestFoo(t* testing.T) ) जो दुर्भाग्यपूर्ण है :(

मेरे पास इसके साथ जो समस्या है वह यह है कि ऐसा होने पर आप हमेशा त्रुटि वापस करना चाहते हैं। जब आप त्रुटि में संदर्भ जोड़ना चाहते हैं और इसे वापस करना चाहते हैं या हो सकता है कि कोई त्रुटि होने पर आप अलग व्यवहार करना चाहते हों। शायद यह लौटाई गई त्रुटि के प्रकार पर निर्भर करता है।

मैं कोशिश/पकड़ के समान कुछ पसंद करूंगा जो दिख सकता है

मान लें कि foo() को परिभाषित किया गया है

func foo() (int, error) {}

आप तब कर सकते थे

n := try(foo()) {
    case FirstError:
        // do something based on FirstError
    case OtherError:
        // do something based on OtherError
    default:
        // default behavior for any other error
}

जो अनुवाद करता है

n, err := foo()
if errors.Is(err, FirstError) {
    // do something based on FirstError
if errors.Is(err, OtherError) {
    // do something based on OtherError
} else {
    // default behavior for any other error
}

मेरे लिए, त्रुटि प्रबंधन कोड आधार के सबसे महत्वपूर्ण भागों में से एक है।
पहले से ही बहुत अधिक गो कोड है if err != nil { return err } , अतिरिक्त संदर्भ जोड़े बिना स्टैक में गहराई से एक त्रुटि लौटा रहा है, या यहां तक ​​​​कि (संभवतः) fmt.Errorf रैपिंग के साथ अंतर्निहित त्रुटि को मास्क करके संदर्भ जोड़ना भी खराब है।

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

func foo() error {
  /// stuff
  try(bar())
  // more stuff
}

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

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

*नोट: यह वास्तव में पुनरावृत्ति को कम नहीं करता है, बस जो दोहराया जा रहा है उसे बदल देता है, जबकि कोड को कम पठनीय बनाता है क्योंकि सब कुछ try() में संलग्न है।

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

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

चूंकि त्रुटि संदर्भ एक आवर्ती विषय प्रतीत होता है ...

परिकल्पना: अधिकांश गो फ़ंक्शन (T, error) के विपरीत (T1, T2, T3, error) लौटाते हैं

क्या होगा अगर, try को try(T1, T2, T3, error) (T1, T2, T3) के रूप में परिभाषित करने के बजाय हमने इसे परिभाषित किया है
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ? (यह एक सन्निकटन है)

जिसका अर्थ यह है कि try कॉल की वाक्य-विन्यास संरचना हमेशा पहला तर्क होता है जो एक अभिव्यक्ति है जो कई मान लौटाता है, जिनमें से अंतिम एक त्रुटि है।

फिर, make की तरह, यह कॉल के 2-तर्क के रूप में द्वार खोलता है, जहां दूसरा तर्क प्रयास का संदर्भ है (उदाहरण के लिए एक निश्चित स्ट्रिंग, %v वाला एक स्ट्रिंग

यह अभी भी (T, error) मामले के लिए जंजीर की अनुमति देता है लेकिन अब आप कई रिटर्न श्रृंखलाबद्ध नहीं कर सकते हैं जो आईएमओ की आमतौर पर आवश्यकता नहीं होती है।

@ cpuguy83 यदि आप प्रस्ताव पढ़ते हैं तो आप देखेंगे कि त्रुटि को लपेटने से आपको कोई रोक नहीं सकता है। वास्तव में try का उपयोग करते हुए इसे करने के कई तरीके हैं। हालांकि कई लोगों को लगता है कि किसी कारण से ऐसा लगता है।

if err != nil { return err } समान रूप से "हम इसे बाद में ठीक कर देंगे" के रूप में try प्रोटोटाइप करते समय अधिक कष्टप्रद को छोड़कर।

मुझे नहीं पता कि कोष्ठक की एक जोड़ी के अंदर की चीजें बॉयलरप्लेट की हर चार पंक्तियों में होने वाले फ़ंक्शन चरणों की तुलना में कम पठनीय हैं।

यह अच्छा होगा यदि आप इनमें से कुछ विशेष "गॉथचास" की ओर इशारा करते हैं जो आपको परेशान करते हैं क्योंकि यह विषय है।

पठनीयता एक मुद्दा प्रतीत होता है, लेकिन गो एफएमटी प्रस्तुत करने की कोशिश के बारे में क्या है () ताकि यह बाहर खड़ा हो, कुछ इस तरह:

f := try(
    os.Open("file.txt")
)

@MrTravisB

मेरे पास इसके साथ जो समस्या है वह यह है कि ऐसा होने पर आप हमेशा त्रुटि वापस करना चाहते हैं।

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

जब आप त्रुटि में संदर्भ जोड़ना चाहते हैं और इसे वापस करना चाहते हैं या हो सकता है कि कोई त्रुटि होने पर आप अलग व्यवहार करना चाहते हों।

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

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

@boomlinde बिल्कुल मेरी बात। यह प्रस्ताव त्रुटि प्रबंधन के बड़े मुद्दे को हल करने के लिए एक उपकरण प्रदान करने के बजाय एक एकल उपयोग के मामले को हल करने का प्रयास कर रहा है। मुझे लगता है कि मौलिक प्रश्न यदि आपने वास्तव में क्या बताया है।

यह मानता है कि आप इतनी बार इतना करना चाहते हैं कि उसके लिए शॉर्टहैंड की गारंटी दी जा सके।

मेरी राय और अनुभव में यह उपयोग मामला एक छोटा अल्पसंख्यक है और शॉर्टहैंड सिंटैक्स की गारंटी नहीं देता है।

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

defer fmt.HandleErrorf(&err, “foobar”)

n := try(foo())

x : try(foo2())

क्या होगा यदि मैं foo() बनाम foo2() से लौटाई जा सकने वाली त्रुटियों के लिए अलग-अलग त्रुटि प्रबंधन चाहता हूं?

@MrTravisB

क्या होगा यदि मैं त्रुटियों के लिए अलग-अलग त्रुटि प्रबंधन चाहता हूं जो foo() बनाम foo2() से वापस किया जा सकता है?

फिर आप कुछ और इस्तेमाल करते हैं। यही बात @boomlinde बना रही थी।

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

@qrpnxz

f := try(os.Open("/foo"))
data := try(ioutil.ReadAll(f))
try(send(data))

(हां, मैं समझता हूं कि ReadFile है और यह विशेष उदाहरण कहीं डेटा कॉपी करने का सबसे अच्छा तरीका नहीं है, बिंदु नहीं)

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

जंग में कम से कम ऑपरेटर एक पोस्टफिक्स है ( ? कॉल के अंत में जोड़ा गया) जो वास्तविक तर्क को खोदने के लिए अतिरिक्त बोझ नहीं डालता है।

अभिव्यक्ति आधारित प्रवाह नियंत्रण

panic एक और प्रवाह नियंत्रण कार्य हो सकता है, लेकिन यह एक मूल्य वापस नहीं करता है, इसे प्रभावी ढंग से एक बयान बना देता है। इसकी तुलना try से करें, जो एक व्यंजक है और कहीं भी हो सकता है।

recover का एक मूल्य है और प्रवाह नियंत्रण को प्रभावित करता है, लेकिन defer कथन में होना चाहिए। ये defer s आम तौर पर कार्य अक्षर होते हैं, recover को केवल एक बार बुलाया जाता है, और इसलिए recover भी प्रभावी रूप से एक कथन के रूप में होता है। दोबारा, इसकी तुलना try से करें जो कहीं भी हो सकता है।

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

एक और प्रस्ताव

जैसे बयानों की अनुमति दें

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

जब ब्लॉक में केवल return स्टेटमेंट होता है और उस स्टेटमेंट में न्यूलाइन्स नहीं होती हैं, तो उसे gofmt द्वारा एक लाइन पर फॉर्मेट करना होता है। उदाहरण के लिए:

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

दलील

• इसके लिए किसी भाषा परिवर्तन की आवश्यकता नहीं है
• स्वरूपण नियम सरल और स्पष्ट है
• नियम को ऑप्ट-इन करने के लिए डिज़ाइन किया जा सकता है जहां gofmt नई लाइनें रखता है यदि वे पहले से मौजूद हैं (जैसे संरचना अक्षर)। ऑप्ट इन भी लेखक को कुछ त्रुटि प्रबंधन पर जोर देने की अनुमति देता है
• यदि यह ऑप्ट इन नहीं है, तो gofmt पर कॉल के साथ कोड को स्वचालित रूप से नई शैली में पोर्ट किया जा सकता है
• यह केवल return स्टेटमेंट के लिए है, इसलिए इसका गोल्फ कोड के साथ अनावश्यक रूप से दुरुपयोग नहीं किया जाएगा
• टिप्पणियों के साथ अच्छी तरह से बातचीत करता है कि कुछ त्रुटियां क्यों हो सकती हैं और उन्हें क्यों लौटाया जा रहा है। कई नेस्टेड try अभिव्यक्तियों का उपयोग करना इसे खराब तरीके से संभालता है
• यह त्रुटि प्रबंधन के ऊर्ध्वाधर स्थान को 66% तक कम कर देता है
• कोई अभिव्यक्ति आधारित नियंत्रण प्रवाह नहीं
• कोड लिखे जाने की तुलना में कहीं अधिक बार पढ़ा जाता है, इसलिए इसे पाठक के लिए अनुकूलित किया जाना चाहिए। कम जगह लेने वाला दोहराव कोड पाठक के लिए मददगार होता है, जहां try लेखक की ओर अधिक झुकता है
• लोग पहले से ही कई लाइनों पर मौजूदा try का प्रस्ताव कर रहे हैं। उदाहरण के लिए यह टिप्पणी या यह टिप्पणी जो एक शैली का परिचय देती है जैसे

f, err := os.Open(file)
try(maybeWrap(err))

• "अपनी लाइन पर प्रयास करें" शैली किसी भी अस्पष्टता को हटा देती है कि err मूल्य क्या लौटाया जा रहा है। इसलिए, मुझे संदेह है कि इस फॉर्म का आमतौर पर इस्तेमाल किया जाएगा। यदि ब्लॉक लगभग समान हैं, तो एक पंक्ति की अनुमति देना, सिवाय इसके कि यह भी स्पष्ट है कि वापसी मान क्या हैं
• यह नामित रिटर्न या अस्पष्ट defer आधारित रैपिंग के उपयोग को बढ़ावा नहीं देता है। दोनों रैपिंग त्रुटियों के लिए बाधा बढ़ाते हैं और पूर्व को godoc परिवर्तनों की आवश्यकता हो सकती है
• पारंपरिक त्रुटि प्रबंधन का उपयोग करते हुए try का उपयोग कब करना है, इस बारे में चर्चा करने की आवश्यकता नहीं है
• भविष्य में try या कुछ और करने से रोकता नहीं है। try स्वीकार किए जाने पर भी परिवर्तन सकारात्मक हो सकता है
• testing लाइब्रेरी या main फ़ंक्शंस के साथ कोई नकारात्मक इंटरैक्शन नहीं। वास्तव में, यदि प्रस्ताव केवल रिटर्न के बजाय किसी एकल पंक्तिबद्ध विवरण की अनुमति देता है, तो यह अभिकथन आधारित पुस्तकालयों के उपयोग को कम कर सकता है। विचार करना

value, err := something()
if err != nil { t.Fatal(err) }

• विशिष्ट त्रुटियों के खिलाफ जाँच के साथ कोई नकारात्मक बातचीत नहीं। विचार करना

n, err := src.Read(buf)
if err == io.EOF { return nil }
else if err != nil { return err }

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

https://github.com/golang/go/issues/32437#issuecomment -498941435 से

कोशिश के साथ

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

इस के साथ

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations))
        if err != nil { return nil, fmt.Errorf("running migrations: %v", err) }

        t := &Thing{thingy: thingy}
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil { return nil, fmt.Errorf("creating scanner: %v", err) }

        t.initOtherThing()
        return t, nil
}

यह अभी भी त्रुटियों के संदर्भ को जोड़ने की अनुमति देते हुए अंतरिक्ष उपयोग में प्रतिस्पर्धी है।

https://github.com/golang/go/issues/32437#issuecomment -499007288 . से

कोशिश के साथ

func (c *Config) Build() error {
    pkgPath := try(c.load())
    b := bytes.NewBuffer(nil)
    try(emplates.ExecuteTemplate(b, "main", c))
    buf := try(format.Source(b.Bytes()))
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644))
    // ...
}

इस के साथ

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

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

@cpuguy83
मेरे लिए यह try के साथ अधिक पठनीय है। इस उदाहरण में मैंने पढ़ा "एक फ़ाइल खोलें, सभी बाइट्स पढ़ें, डेटा भेजें"। नियमित त्रुटि प्रबंधन के साथ मैं पढ़ूंगा "एक फ़ाइल खोलें, जांचें कि क्या कोई त्रुटि थी, त्रुटि प्रबंधन यह करता है, फिर सभी बाइट्स पढ़ें, अब जांचें कि क्या कुछ हुआ ..." मुझे पता है कि आप err != nil के माध्यम से स्कैन कर सकते हैं try बस आसान है क्योंकि जब मैं इसे देखता हूं तो मुझे तुरंत व्यवहार पता चल जाता है: अगर गलती होती है तो रिटर्न! = शून्य। यदि आपके पास एक शाखा है तो मुझे देखना होगा कि वह क्या करती है। यह कुछ भी कर सकता था।

मैं यह भी तर्क दूंगा कि एक नए संदेश के साथ त्रुटि को लपेटने के अलावा यहां एक स्थगित त्रुटि हैंडलर अच्छा नहीं होगा

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

@zeebo हाँ, मैं उसमें हूँ।
@kungfusheep के लेख में इस तरह की एक लाइन एरर चेक का इस्तेमाल किया गया और मैं इसे आज़माने के लिए बाहर निकल गया। फिर जैसे ही मैंने सेव किया, gofmt ने इसे तीन पंक्तियों में विस्तारित किया जो दुखद था। Stdlib में कई कार्यों को एक पंक्ति में परिभाषित किया गया है, इसलिए मुझे आश्चर्य हुआ कि gofmt इसका विस्तार करेगा।

@qrpnxz

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

यह if err != nil { return err } से निष्पक्ष रूप से बेहतर नहीं है, टाइप करने के लिए बस कम है।

एक अंतिम बात:

यदि आप प्रस्ताव पढ़ते हैं तो आप देखेंगे कि कोई भी चीज आपको रोक नहीं रही है

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

@cpuguy83
मेरा बुरा सीपीयू आदमी। मेरा मतलब उस तरह से नहीं था।

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

निश्चित रूप से यह निष्पक्ष रूप से बेहतर नहीं है। मैं व्यक्त कर रहा था कि यह मेरे लिए उस तरह से अधिक पठनीय था। मैंने इसे ध्यान से कहा।

दोबारा, इस तरह से आवाज उठाने के लिए खेद है। हालांकि यह एक तर्क है, मेरा मतलब आपका विरोध करना नहीं था।

https://github.com/golang/go/issues/32437#issuecomment -498908380

कोई भी आपको कोशिश का उपयोग करने वाला नहीं है।

चमक को नजरअंदाज करते हुए, मुझे लगता है कि यह एक डिजाइन आलोचना को खारिज करने का एक सुंदर तरीका है।

ज़रूर, मुझे इसका इस्तेमाल करने की ज़रूरत नहीं है। लेकिन जिस किसी के साथ मैं कोड लिखता हूं वह इसका इस्तेमाल कर सकता है और मुझे try(try(try(to()).parse().this)).easily()) को समझने की कोशिश करने के लिए मजबूर कर सकता है। यह कहने जैसा है

कोई भी आपको खाली इंटरफ़ेस का उपयोग करने के लिए नहीं कहेगा {}।

वैसे भी, सरलता के बारे में गो बहुत सख्त है: gofmt सभी कोड को एक जैसा दिखता है। सुखी पथ बाएँ रहता है और जो कुछ भी महंगा या आश्चर्यजनक हो सकता है वह स्पष्ट है। try जैसा कि प्रस्तावित है, इससे 180 डिग्री मोड़ है। सरलता! = संक्षिप्त।

कम से कम try अंतराल के साथ एक कीवर्ड होना चाहिए।

यह _objectively_ if err != nil { return err } से बेहतर नहीं है, टाइप करने के लिए बस कम है।

दोनों के बीच एक वस्तुनिष्ठ अंतर है: try(Foo()) एक व्यंजक है। कुछ के लिए, यह अंतर एक नकारात्मक पहलू है ( try(strconv.Atoi(x))+try(strconv.Atoi(y)) आलोचना)। दूसरों के लिए, यह अंतर उसी कारण से उल्टा है। अभी भी निष्पक्ष रूप से बेहतर या बदतर नहीं है - लेकिन मुझे यह भी नहीं लगता कि अंतर को गलीचा के नीचे बह जाना चाहिए और यह दावा करना कि यह "बस कम टाइप करने के लिए" प्रस्ताव न्याय नहीं करता है।

@ elagergren-spideroak यह कहना मुश्किल है कि try एक सांस में देखने के लिए परेशान है और फिर कहें कि यह अगले में स्पष्ट नहीं है। आपको एक चुनना होगा।

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

this := try(to()).parse().this
that := try(this.easily())

आपके उदाहरण से।

try कुछ भी नहीं करना खुशी का रास्ता है, इसलिए यह उम्मीद के मुताबिक दिखता है। दुखी पथ में यह केवल वापसी ही करता है। वहाँ देखना try है जो उस जानकारी को इकट्ठा करने के लिए पर्याप्त है। किसी फ़ंक्शन से लौटने के बारे में कुछ भी महंगा नहीं है, इसलिए उस विवरण से मुझे नहीं लगता कि try 180 कर रहा है

@josarian https://github.com/golang/go/issues/32437#issuecomment -498941854 में आपकी टिप्पणी के संबंध में, मुझे नहीं लगता कि यहां प्रारंभिक मूल्यांकन त्रुटि है।

defer fmt.HandleErrorf(&err, "foobar: %v", err)

err HandleErrorf पास किया जाता है, और err के लिए एक पॉइंटर पास किया जाता है। हम जांचते हैं कि क्या err nil है (सूचक का उपयोग करके)। यदि नहीं, तो हम err के असंशोधित मान का उपयोग करके स्ट्रिंग को प्रारूपित करते हैं। फिर हम पॉइंटर का उपयोग करके err को स्वरूपित त्रुटि मान पर सेट करते हैं।

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

@ianlancetaylor , मुझे लगता है कि @josharian सही है: err का "अनमॉडिफाइड" मान उस समय का मूल्य है जब defer को स्टैक पर धकेला जाता है, न कि (संभवतः इच्छित) मूल्य err लौटने से पहले try द्वारा निर्धारित।

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

this := try(to()).parse().this
that := try(this.easily())

^^ यह भी सर्वथा भयानक है। पहली पंक्ति, मुझे अपने सिर में पैरेन मिलान करते हुए आगे-पीछे कूदना है। यहां तक ​​कि दूसरी पंक्ति जो वास्तव में काफी सरल है... को पढ़ना वाकई मुश्किल है।
नेस्टेड कार्यों को पढ़ना मुश्किल है।

parser, err := to()
if err != nil {
    return err
}
this := parser.parse().this
that, err := this.easily()
if err != nil {
    return err
}

^^ यह इतना आसान और बेहतर आईएमओ है। यह सुपर सरल और स्पष्ट है। हाँ, यह कोड की बहुत अधिक पंक्तियाँ हैं, मुझे परवाह नहीं है। यह बहुत स्पष्ट है।

@bcmills @josharian आह, बिल्कुल, धन्यवाद। तो यह होना ही होगा

defer func() { fmt.HandleErrorf(&err, “foobar: %v”, err) }()

इतना अच्छा नही है। हो सकता है कि fmt.HandleErrorf को अंतिम तर्क के रूप में त्रुटि मान को निहित रूप से पास करना चाहिए।

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

@ianlancetaylor अगर fmt.HandleErrorf प्रारूप के बाद पहले तर्क के रूप में गलती भेजता है तो कार्यान्वयन अच्छा होगा और उपयोगकर्ता इसे हमेशा %[1]v द्वारा संदर्भित करने में सक्षम होगा।

@natefinch बिल्कुल सहमत हैं।

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

this := to()?.parse().this
that := this.easily()?

अंत में मुझे लगता है कि यह अच्छा है, लेकिन ( ! या कुछ और भी उपयोग कर सकता है ...), लेकिन फिर भी त्रुटियों को अच्छी तरह से संभालने के मुद्दे को ठीक नहीं करता है।

बेशक जंग में भी try() बहुत कुछ इसी तरह है, लेकिन ... अन्य जंग शैली।

यह _objectively_ if err != nil { return err } से बेहतर नहीं है, टाइप करने के लिए बस कम है।

दोनों के बीच एक वस्तुनिष्ठ अंतर है: try(Foo()) एक व्यंजक है। कुछ के लिए, यह अंतर एक नकारात्मक पहलू है ( try(strconv.Atoi(x))+try(strconv.Atoi(y)) आलोचना)। दूसरों के लिए, यह अंतर उसी कारण से उल्टा है। अभी भी निष्पक्ष रूप से बेहतर या बदतर नहीं है - लेकिन मुझे यह भी नहीं लगता कि अंतर को गलीचा के नीचे बह जाना चाहिए और यह दावा करना कि यह "बस कम टाइप करने के लिए" प्रस्ताव न्याय नहीं करता है।

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

@MrTravisB

बिल्कुल मेरी बात। यह प्रस्ताव त्रुटि प्रबंधन के बड़े मुद्दे को हल करने के लिए एक उपकरण प्रदान करने के बजाय एक एकल उपयोग के मामले को हल करने का प्रयास कर रहा है। मुझे लगता है कि मौलिक प्रश्न यदि आपने वास्तव में क्या बताया है।

मैंने विशेष रूप से क्या कहा जो आपकी बात है? बल्कि मुझे ऐसा लगता है कि यदि आपको लगता है कि हम सहमत हैं तो आपने मेरी बात को मूल रूप से गलत समझा।

मेरी राय और अनुभव में यह उपयोग मामला एक छोटा अल्पसंख्यक है और शॉर्टहैंड सिंटैक्स की गारंटी नहीं देता है।

गो स्रोत में ऐसे हजारों मामले हैं जिन्हें बॉक्स से बाहर try द्वारा नियंत्रित किया जा सकता है, भले ही त्रुटियों में संदर्भ जोड़ने का कोई तरीका न हो। यदि नाबालिग है, तो यह अभी भी शिकायत का एक सामान्य कारण है।

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

इसी तरह, अंकगणित को संभालने के लिए + का उपयोग करने का दृष्टिकोण मानता है कि आप घटाना नहीं चाहते हैं, इसलिए यदि आप नहीं करते हैं तो आप नहीं करते हैं। दिलचस्प सवाल यह है कि क्या ब्लॉक-वाइड त्रुटि संदर्भ कम से कम एक सामान्य पैटर्न का प्रतिनिधित्व करता है।

क्या होगा यदि मैं त्रुटियों के लिए अलग-अलग त्रुटि प्रबंधन चाहता हूं जो foo() बनाम foo2() से वापस किया जा सकता है

फिर, आप try का उपयोग नहीं करते हैं। तब आपको try से कुछ नहीं मिलता, लेकिन आप कुछ भी नहीं खोते।

@cpuguy83

मुझे आश्चर्य है कि क्या जंग शैली का दृष्टिकोण अधिक स्वादिष्ट होगा?

प्रस्ताव इसके खिलाफ तर्क प्रस्तुत करता है।

इस बिंदु पर, मुझे लगता है कि try{}catch{} अधिक पठनीय है: upside_down_face:

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

2. कोई भी आपको कोशिश का उपयोग करने वाला नहीं है।

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

3. मुझे लगता है कि try(try(try(to()).parse().this)).easily()) जैसे उदाहरण अवास्तविक हैं, यह पहले से ही अन्य कार्यों के साथ किया जा सकता है और मुझे लगता है कि कोड की समीक्षा करने वालों के लिए इसे विभाजित करने के लिए पूछना उचित होगा।

4. क्या होगा यदि मेरे पास 3 स्थान हैं जो त्रुटि-बाहर कर सकते हैं और मैं प्रत्येक स्थान को अलग से लपेटना चाहता हूं? try() इसे बहुत कठिन बनाता है, वास्तव में try() पहले से ही इसकी कठिनाई को देखते हुए रैपिंग त्रुटियों को हतोत्साहित कर रहा है, लेकिन यहां मेरा मतलब है कि इसका एक उदाहरण है:

   func before() error {
     x, err := foo()
     if err != nil {
       wrap(err, "error on foo")
     }
     y, err := bar(x)
     if err != nil {
       wrapf(err, "error on bar with x=%v", x)
     }
     fmt.Println(y)
     return nil
   }
   
   func after() (err error) {
     defer fmt.HandleErrorf(&err, "something failed but I don't know where: %v", err)
     x := try(foo())
     y := try(bar(x))
     fmt.Println(y)
     return nil
   }
   

5. फिर, आप try का उपयोग नहीं करते हैं। तब आपको try से कुछ नहीं मिलता है, लेकिन आप कुछ भी नहीं खोते हैं।

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

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

@boomlinde जिस बिंदु पर हम सहमत हैं वह यह है कि यह प्रस्ताव मामूली उपयोग के मामले को हल करने का प्रयास कर रहा है और तथ्य यह है कि "यदि आपको इसकी आवश्यकता नहीं है, तो इसका उपयोग न करें" इसके लिए प्राथमिक तर्क उस बिंदु को आगे बढ़ाता है। जैसा कि @ elagergren-spideroak ने कहा, वह तर्क काम नहीं करता है क्योंकि भले ही मैं इसका उपयोग नहीं करना चाहता, अन्य लोग करेंगे जो मुझे इसका उपयोग करने के लिए मजबूर करते हैं। आपके तर्क के तर्क से गो का भी एक त्रिगुट कथन होना चाहिए। और अगर आपको टर्नरी स्टेटमेंट पसंद नहीं हैं, तो उनका इस्तेमाल न करें।

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

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

func exists(filename string) bool {
  _, err := os.Stat(filename)
  return err == nil
}

if exists(...) { ... } लिखने में सक्षम होने के लिए, भले ही यह कोड चुपचाप कुछ संभावित त्रुटियों को अनदेखा करता है। अगर मेरे पास try होता, तो शायद मैं ऐसा करने की जहमत नहीं उठाता और बस (bool, error) लौटा देता।

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

func catch(handler func(err error) error) {
  // .. impl ..
}

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

func wrapf(format string, ...values interface{}) func(err error) error {
  // user defined
  return func(err error) error {
    return fmt.Errorf(format + ": %v", ...append(values, err))
  }
}
func sample() {
  catch(wrapf("something failed in foo"))
  try(foo()) // "something failed in foo: <error>"
  x := try(foo2()) // "something failed in foo: <error>"
  // Subsequent calls for catch overwrite the handler
  catch(wrapf("something failed in bar with x=%v", x))
  try(bar(x)) // "something failed in bar with x=-1: <error>"
}

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

func foo(a, b string) (int64, error) {
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func withContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, b: %s, err: %v", a, b, err)
  })
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func moreExplicitContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, err: %v", a, err)
  })
  x := try(strconv.Atoi(a))
  catch(func (err error) error {
    return fmt.Errorf("can't parse b: %s, err: %v", b, err)
  })
  y := try(strconv.Atoi(b))
  return x + y
}
func withHelperWrapf(a, b string) (int64, error) {
  catch(wrapf("can't parse a: %s", a))
  x := try(strconv.Atoi(a))
  catch(wrapf("can't parse b: %s", b))
  y := try(strconv.Atoi(b))
  return x + y
}
func before(a, b string) (int64, error) {
  x, err := strconv.Atoi(a)
  if err != nil {
    return 0,  fmt.Errorf("can't parse a: %s, err: %v", a, err)
  }
  y, err := strconv.Atoi(b)
  if err != nil {
    return 0,  fmt.Errorf("can't parse b: %s, err: %v", b, err)
  }
  return x + y
}

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

अब... मैं वास्तव में अंतिम वाक्य से मतलब नहीं रखता, लेकिन ऐसा लगता है कि यह चर्चा के लिए उपयोगी नहीं है, बहुत आक्रामक आईएमओ।
फिर भी, अगर हम इस मार्ग पर गए तो मुझे लगता है कि हमारे पास इसके बजाय try{}catch(error err){} भी हो सकता है :stuck_out_tongue:

यह भी देखें #27519 - #id/catch त्रुटि मॉडल

कोई भी आपको कोशिश का उपयोग करने वाला नहीं है।

चमक को नजरअंदाज करते हुए, मुझे लगता है कि यह एक डिजाइन आलोचना को खारिज करने का एक सुंदर तरीका है।

क्षमा करें, ग्लिब मेरा इरादा नहीं था।

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

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

तो "कोई भी आपको कोशिश का उपयोग करने वाला नहीं है", मेरा मतलब है कि मुझे लगता है कि प्रश्न में उदाहरण 10% में है, न कि 90%। यह दावा निश्चित रूप से बहस के लिए तैयार है, और मुझे प्रतिवाद सुनकर खुशी हुई। लेकिन अंततः हमें कहीं रेखा खींचनी होगी और कहना होगा "हाँ, try उस मामले को संभाल नहीं पाएगा। आपको पुरानी शैली की त्रुटि प्रबंधन का उपयोग करना होगा। क्षमा करें।"।

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

इस प्रस्ताव के तहत आपको defer के साथ नामित रिटर्न का उपयोग करने की आवश्यकता है, जो सहज नहीं है और बहुत हैकी लगता है।

check-handle विचार ने आपको एक रिटर्न स्टेटमेंट लिखने के लिए मजबूर किया, इसलिए एक त्रुटि रैपिंग लिखना बहुत छोटा था।

यह सच नहीं है - डिज़ाइन ड्राफ्ट में, त्रुटि देने वाले प्रत्येक फ़ंक्शन में एक डिफ़ॉल्ट हैंडलर होता है जो केवल त्रुटि देता है।

@Goodwine के प्रभाव बिंदु पर निर्माण, आपको वास्तव में HandleErrorf जैसे अलग-अलग कार्यों की आवश्यकता नहीं है यदि आपके पास एक एकल ब्रिज फ़ंक्शन है

func handler(err *error, handle func(error) error) {
  // nil handle is treated as the identity
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

जिसे आप पसंद करेंगे

defer handler(&err, func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

आप handler को try की तरह एक अर्ध-जादुई बिलिन बना सकते हैं।

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

defer handler(func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

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

चूंकि यह defer का उपयोग करता है, इसलिए जब भी कोई गैर-शून्य त्रुटि लौटाई जा रही थी, तो यह handle func को कॉल कर सकता था, इसे try के बिना भी उपयोगी बना देता था क्योंकि आप एक जोड़ सकते थे

defer handler(wrapErrWithPackageName)

शीर्ष पर fmt.Errorf("mypkg: %w", err) सब कुछ।

यह आपको बहुत पुराने check / handle प्रस्ताव देता है लेकिन यह आवश्यकता से छुटकारा पाने के दौरान स्वाभाविक रूप से (और स्पष्ट रूप से) स्थगित के साथ काम करता है, ज्यादातर मामलों में, स्पष्ट रूप से err नाम देने के लिए try की तरह यह एक अपेक्षाकृत सीधा मैक्रो है जिसे (मुझे लगता है) पूरी तरह से सामने के अंत में लागू किया जा सकता है।

यह सच नहीं है - डिज़ाइन ड्राफ्ट में, त्रुटि देने वाले प्रत्येक फ़ंक्शन में एक डिफ़ॉल्ट हैंडलर होता है जो केवल त्रुटि देता है।

मेरा बुरा, तुम सही हो।

मेरा मतलब है कि मुझे लगता है कि प्रश्न में उदाहरण 10% में है, 90% नहीं। यह दावा निश्चित रूप से बहस के लिए तैयार है, और मुझे प्रतिवाद सुनकर खुशी हुई। लेकिन अंततः हमें कहीं न कहीं रेखा खींचनी होगी और कहना होगा "हाँ, कोशिश उस मामले को संभाल नहीं पाएगी। आपको पुरानी शैली की त्रुटि प्रबंधन का उपयोग करना होगा। क्षमा करें।"।

सहमत, मेरी राय यह है कि ईओएफ या इसी तरह की जांच करते समय यह रेखा खींची जानी चाहिए, रैपिंग पर नहीं। लेकिन हो सकता है कि अगर त्रुटियों में अधिक संदर्भ होता तो यह अब कोई मुद्दा नहीं होता।

डीबगिंग के लिए उपयोगी संदर्भ के साथ try() ऑटो-रैप त्रुटियां हो सकती हैं? उदाहरण के लिए यदि xerrors errors #$ बन जाता है, तो त्रुटियों में कुछ ऐसा होना चाहिए जो स्टैक ट्रेस जैसा दिखता है जिसे try() जोड़ सकता है, नहीं? अगर ऐसा है तो शायद इतना ही काफी होगा

यदि लक्ष्य हैं (पढ़ना https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md):

• बॉयलरप्लेट को खत्म करें
• न्यूनतम भाषा परिवर्तन
• "सबसे आम परिदृश्य" को कवर करना
• भाषा में बहुत कम जटिलता जोड़ना

मैं सुझाव लेता हूं कि इसे एक कोण दें और कोड की सभी अरबों लाइनों के लिए "छोटे कदम" कोड माइग्रेशन की अनुमति दें।

सुझाए गए के बजाय:

func printSum(a, b string) error {
        defer fmt.HandleErrorf(&err, "sum %s %s: %v", a,b, err) 
        x := try(strconv.Atoi(a))
        y := try(strconv.Atoi(b))
        fmt.Println("result:", x + y)
        return nil
}

वे कैन:

func printSum(a, b string) error {
        var err ErrHandler{HandleFunc : twoStringsErr("printSum",a,b)} 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

हमें क्या हासिल होगा?
twoStringsErr को प्रिंटसम, या एक सामान्य हैंडलर में इनलाइन किया जा सकता है जो जानता है कि त्रुटियों को कैसे कैप्चर किया जाए (इस मामले में 2 स्ट्रिंग पैरामीटर के साथ) - इसलिए यदि मेरे पास मेरे कई कार्यों में उपयोग किए जाने वाले एक ही दोहराए जाने वाले func हस्ताक्षर हैं, तो मुझे प्रत्येक हैंडलर को फिर से लिखने की आवश्यकता नहीं है समय
उसी तरह, मैं ErrHandler प्रकार को इस प्रकार विस्तारित कर सकता हूं:

type ioErrHandler ErrHandler
func (i ErrHandler) Handle() ...{

}

या

type parseErrHandler ErrHandler
func (p parseErrHandler) Handle() ...{

}

या

type str2IntErrHandler ErrHandler
func (s str2IntErrHandler) Handle() ...{

}

और इसे मेरे मेरे कोड के चारों ओर उपयोग करें:

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

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

func (s str2IntErrHandler) Handle() bool{
   **return false**
}

जो कॉलिंग फंक्शन को रिटर्न के बजाय जारी रखने के लिए कहेगा

और एक ही फ़ंक्शन में विभिन्न त्रुटि हैंडलर का उपयोग करें:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        var oErr overflowError 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        totalAsByte,oErr := sumBytes(x,y)
        sunAsByte,oErr := subtractBytes(x,y)
        return nil
}

आदि।

फिर से लक्ष्यों पर जा रहे हैं

• बॉयलरप्लेट को खत्म करें - किया गया
• न्यूनतम भाषा परिवर्तन - हो गया
• "सबसे आम परिदृश्य" को कवर करना - सुझाए गए IMO से अधिक
• भाषा में बहुत कम जटिलता जोड़ना - सोन
  प्लस - से आसान कोड माइग्रेशन

x, err := strconv.Atoi(a)

प्रति

x, err.Error := strconv.Atoi(a)

और वास्तव में - बेहतर पठनीयता (आईएमओ, फिर से)

@guybrand आप इस आवर्ती विषय (जो मुझे पसंद है) के नवीनतम अनुयायी हैं।

देखें https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

@guybrand यह एक पूरी तरह से अलग प्रस्ताव की तरह लगता है; मुझे लगता है कि आपको इसे अपने मुद्दे के रूप में दर्ज करना चाहिए ताकि यह @griesemer के प्रस्ताव पर चर्चा करने पर ध्यान केंद्रित कर सके।

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

@अच्छी शराब

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

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

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

केवल यह कहने के बजाय कि "ठीक है, अगर आपको यह पसंद नहीं है, तो इसका उपयोग न करें और चुप रहें" (यह इस तरह से पढ़ता है), मुझे लगता है कि यह पता लगाने की कोशिश करना बेहतर होगा कि कितने उपयोग दोष पर विचार कर रहे हैं डिजाइन में।

अगर ऐसा पढ़ता है तो मैं क्षमा चाहता हूं। मेरा कहना यह नहीं है कि अगर आपको यह पसंद नहीं है तो आपको यह दिखावा करना चाहिए कि यह मौजूद नहीं है। यह स्पष्ट है कि ऐसे मामले हैं जिनमें try बेकार होगा और आपको ऐसे मामलों में इसका उपयोग नहीं करना चाहिए, जो इस प्रस्ताव के लिए मेरा मानना ​​​​है कि KISS और सामान्य उपयोगिता के बीच एक अच्छा संतुलन है। मुझे नहीं लगता था कि मैं उस बिंदु पर अस्पष्ट था।

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

0) सकारात्मक पक्ष पर, @rasky , @adg , @eandre , @dpinela , और अन्य ने try द्वारा प्रदान किए गए कोड सरलीकरण पर स्पष्ट रूप से खुशी व्यक्त की।

1) सबसे महत्वपूर्ण चिंता यह प्रतीत होती है कि try अच्छी त्रुटि प्रबंधन शैली को प्रोत्साहित नहीं करता बल्कि इसके बजाय "त्वरित निकास" को बढ़ावा देता है। ( @agnivade , @peterbourgon , @politician , @a8m , @eandre , @prologic , @kungfusheep , @cpuguy , और अन्य ने इस बारे में अपनी चिंता व्यक्त की है।)

2) बहुत से लोग बिल्ट-इन या इसके साथ आने वाले फ़ंक्शन सिंटैक्स के विचार को पसंद नहीं करते हैं क्योंकि यह एक return छुपाता है। कीवर्ड का उपयोग करना बेहतर होगा। ( @sheerun , @Redundancy , @dolmen , @komuw , @RobertGrantEllis , @elagergren-spideroak)। try को भी आसानी से अनदेखा किया जा सकता है (@peterbourgon), विशेष रूप से क्योंकि यह ऐसे भावों में प्रकट हो सकता है जो मनमाने ढंग से नेस्टेड हो सकते हैं। @natefinch चिंतित है कि try इसे "एक पंक्ति में बहुत अधिक डंप करना बहुत आसान" बनाता है, कुछ ऐसा जिसे हम आमतौर पर गो से बचने की कोशिश करते हैं। साथ ही, try पर जोर देने के लिए IDE समर्थन पर्याप्त नहीं हो सकता (@dominikh); try को "अपने दम पर खड़ा होना" चाहिए।

3) कुछ के लिए, स्पष्ट if बयानों की यथास्थिति कोई समस्या नहीं है, वे इससे खुश हैं ( @bitfield , @marwan-at-work, @natefinch)। चीजों को करने का केवल एक ही तरीका होना बेहतर है (@gbbr); और स्पष्ट if कथन निहित return ( @DavexPro , @hmage , @prologic , @natefinch) से बेहतर हैं।
उसी पंक्तियों के साथ, @mattn त्रुटि परिणाम के "अंतर्निहित बाध्यकारी" के बारे में चिंतित है try - कोड में कनेक्शन स्पष्ट रूप से दिखाई नहीं दे रहा है।

4) try का उपयोग करने से कोड डीबग करना कठिन हो जाएगा; उदाहरण के लिए, try एक्सप्रेशन को वापस if स्टेटमेंट में फिर से लिखना आवश्यक हो सकता है ताकि डिबगिंग स्टेटमेंट डाला जा सके ( @deanveloper , @typeless , @networkimprov , अन्य)।

5) नामित रिटर्न ( @buchanae , @adg) के उपयोग के बारे में कुछ चिंता है।

प्रस्ताव में सुधार या संशोधन के लिए कई लोगों ने सुझाव दिए हैं:

6) कुछ ने वैकल्पिक त्रुटि हैंडलर (@beoran) या try ( @unexge , @a8m , @eandre , @gotwarlost) को प्रदान की गई प्रारूप स्ट्रिंग के विचार पर विचार किया है ताकि अच्छी त्रुटि प्रबंधन को प्रोत्साहित किया जा सके।

7) @pierrec ने सुझाव दिया कि gofmt try अभिव्यक्तियों को उपयुक्त रूप से प्रारूपित कर सकता है ताकि उन्हें अधिक दृश्यमान बनाया जा सके।
वैकल्पिक रूप से, कोई व्यक्ति gofmt को if स्टेटमेंट को एक लाइन (@zeebo) पर त्रुटियों की जांच करने की अनुमति देकर मौजूदा कोड को अधिक कॉम्पैक्ट बना सकता है।

8) @ मारवान-एट-वर्क का तर्क है कि try बस त्रुटि प्रबंधन को if स्टेटमेंट से try एक्सप्रेशन में बदल देता है। इसके बजाय, यदि हम वास्तव में समस्या को हल करना चाहते हैं, तो गो को वास्तव में निहित बनाकर त्रुटि प्रबंधन को "स्वयं" करना चाहिए। लक्ष्य (उचित) त्रुटि को सरल और डेवलपर्स को अधिक उत्पादक बनाना होना चाहिए (@cpuguy)।

9) अंत में, कुछ लोग try ( @beoran , @HiImJC , @dolmen) नाम पसंद नहीं करते हैं या ? ( @twisted1919 , @leaxoy , अन्य) जैसे प्रतीक को पसंद करेंगे। .

इस प्रतिक्रिया पर कुछ टिप्पणियाँ (तदनुसार क्रमांकित):

0) सकारात्मक प्रतिक्रिया के लिए धन्यवाद! :-)

1) इस चिंता के बारे में और जानना अच्छा होगा। त्रुटियों के परीक्षण के लिए if कथनों का उपयोग करने वाली वर्तमान कोडिंग शैली लगभग उतनी ही स्पष्ट है जितनी यह हो सकती है। व्यक्तिगत आधार पर (प्रत्येक if के लिए) त्रुटि में अतिरिक्त जानकारी जोड़ना बहुत आसान है। अक्सर किसी फ़ंक्शन में पाई गई सभी त्रुटियों को एक समान तरीके से संभालना समझ में आता है, जिसे defer के साथ किया जा सकता है - यह अब पहले से ही संभव है। यह तथ्य है कि भाषा में अच्छी त्रुटि प्रबंधन के लिए हमारे पास पहले से ही सभी उपकरण हैं, और एक हैंडलर निर्माण की समस्या defer के लिए ऑर्थोगोनल नहीं है, जिसके कारण हमें केवल त्रुटियों को बढ़ाने के लिए एक नया तंत्र छोड़ना पड़ा .

2) निश्चित रूप से बिल्ट-इन के बजाय किसी कीवर्ड या विशेष सिंटैक्स का उपयोग करने की संभावना है। एक नया खोजशब्द पश्चगामी-संगत नहीं होगा। एक नया ऑपरेटर हो सकता है, लेकिन इससे भी कम दिखाई देता है। विस्तृत प्रस्ताव में विभिन्न पेशेवरों और विपक्षों पर विस्तार से चर्चा की गई है। लेकिन शायद हम इसे गलत समझ रहे हैं।

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

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

5) नामांकित वापसी मूल्य: विस्तृत दस्तावेज़ इस पर विस्तार से चर्चा करता है। अगर इस प्रस्ताव के बारे में यह मुख्य चिंता है तो हम एक अच्छे स्थान पर हैं, मुझे लगता है।

6) वैकल्पिक हैंडलर तर्क try : विस्तृत दस्तावेज़ इस पर भी चर्चा करता है। डिज़ाइन पुनरावृत्तियों पर अनुभाग देखें।

7) gofmt का उपयोग $ try अभिव्यक्तियों को प्रारूपित करने के लिए करना ताकि वे अतिरिक्त दृश्यमान हों, निश्चित रूप से एक विकल्प होगा। लेकिन यह किसी व्यंजक में उपयोग किए जाने पर try के कुछ लाभों से दूर ले जाएगा।

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

9) क्या मैं सुझाव दे सकता हूं कि हम इस समय नाम को बाइक-शेड नहीं करते हैं। एक बार जब अन्य सभी चिंताओं का समाधान हो जाता है तो नाम को ठीक करने का बेहतर समय होता है।

यह कहना नहीं है कि चिंताएँ मान्य नहीं हैं - ऊपर दिए गए उत्तर केवल हमारी वर्तमान सोच को बता रहे हैं। आगे बढ़ते हुए, नई चिंताओं (या इन चिंताओं के समर्थन में नए साक्ष्य) पर टिप्पणी करना अच्छा होगा - जो पहले ही कहा जा चुका है उसे केवल पुन: स्थापित करने से हमें अधिक जानकारी नहीं मिलती है।

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

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

func try(t1 T1, t1 T2, … tn Tn, te error) (T1, T2, … Tn)

होना चाहिए:

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

क्या त्रुटि जाँच कथनों के लिए खुले तौर पर उपलब्ध गो कोड का विश्लेषण करने और यह पता लगाने के लायक होगा कि क्या अधिकांश त्रुटि जाँच वास्तव में दोहराई जाती हैं या यदि ज्यादातर मामलों में, एक ही फ़ंक्शन के भीतर कई जाँचें अलग-अलग प्रासंगिक जानकारी जोड़ती हैं? प्रस्ताव पहले मामले के लिए बहुत मायने रखता है लेकिन बाद के मामले में मदद नहीं करेगा। बाद के मामले में, लोग या तो if err != nil का उपयोग करना जारी रखेंगे या अतिरिक्त संदर्भ जोड़ना छोड़ देंगे, try() का उपयोग करेंगे और प्रति फ़ंक्शन सामान्य त्रुटि संदर्भ जोड़ने का सहारा लेंगे जो IMO हानिकारक होगा। आगामी त्रुटि मान सुविधाओं के साथ, मुझे लगता है कि हम उम्मीद करते हैं कि लोग त्रुटियों को अधिक जानकारी के साथ अधिक बार लपेटेंगे। शायद मैंने प्रस्ताव को गलत समझा लेकिन एएफएआईयू, यह केवल बॉयलरप्लेट को कम करने में मदद करता है जब एक फ़ंक्शन से सभी त्रुटियों को बिल्कुल एक तरह से लपेटा जाना चाहिए और यदि कोई फ़ंक्शन पांच त्रुटियों से निपटता है तो अलग-अलग लपेटने की आवश्यकता हो सकती है। निश्चित नहीं है कि जंगली में ऐसे मामले कितने आम हैं (मेरी अधिकांश परियोजनाओं में बहुत आम हैं) लेकिन मुझे चिंता है कि try() लोगों को प्रति फ़ंक्शन सामान्य रैपर का उपयोग करने के लिए प्रोत्साहित कर सकता है, भले ही यह अलग-अलग त्रुटियों को लपेटने के लिए समझ में आए अलग ढंग से।

एक छोटे से नमूना सेट के डेटा के साथ समर्थित एक त्वरित टिप्पणी:

हम एक नए बिल्ट-इन फ़ंक्शन का प्रस्ताव करते हैं, जिसे ट्राई कहा जाता है, जिसे विशेष रूप से बॉयलरप्लेट को खत्म करने के लिए डिज़ाइन किया गया है, यदि स्टेटमेंट आमतौर पर Go . में एरर हैंडलिंग से जुड़े होते हैं

अगर यह इस प्रस्ताव द्वारा हल की जा रही मुख्य समस्या है, तो मुझे लगता है कि यह "बॉयलरप्लेट" केवल ~ 60k एसएलओसी की कुल दर्जनों सार्वजनिक रूप से उपलब्ध ओपन सोर्स परियोजनाओं में मेरे कोड का ~ 1.4% है।

उत्सुक अगर किसी और के पास समान आँकड़े हैं?

गो जैसे बहुत बड़े कोडबेस पर, कुल मिलाकर लगभग ~1.6M SLOC, यह कोडबेस के लगभग ~0.5% के बराबर होता है, जिसमें if err != nil जैसी लाइनें होती हैं।

क्या यह वास्तव में Go 2 के साथ हल करने वाली सबसे प्रभावशाली समस्या है?

हर किसी के विचारों को समझने और स्पष्ट रूप से विचार प्रदान करने के लिए समय निकालने के लिए @griesemer का बहुत-बहुत धन्यवाद। मुझे लगता है कि यह वास्तव में इस धारणा में मदद करता है कि प्रक्रिया में समुदाय को सुना जा रहा है।

1. @pierrec ने सुझाव दिया कि gofmt उन्हें और अधिक दृश्यमान बनाने के लिए उपयुक्त रूप से कोशिश करने वाले भावों को प्रारूपित कर सकता है।
   वैकल्पिक रूप से, यदि एक पंक्ति (@zeebo) पर त्रुटियों की जाँच करने वाले कथनों की जाँच करने के लिए gofmt को प्रारूपित करने की अनुमति देकर कोई मौजूदा कोड को अधिक कॉम्पैक्ट बना सकता है।

1. gofmt का उपयोग $# try अभिव्यक्तियों को प्रारूपित करने के लिए करना ताकि वे अतिरिक्त दृश्यमान हों, निश्चित रूप से एक विकल्प होगा। लेकिन यह एक व्यंजक में उपयोग किए जाने पर try के कुछ लाभों से दूर ले जाएगा।

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

@griesemer सभी टिप्पणियों के माध्यम से अविश्वसनीय काम के लिए धन्यवाद और यदि सभी प्रतिक्रिया नहीं तो सबसे अधिक उत्तर दें

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

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

@griesemer मुझे यकीन है कि यह अच्छी तरह से सोचा नहीं गया है, लेकिन मैंने आपके सुझाव को कुछ इस तरह से संशोधित करने की कोशिश की है कि मैं यहां सहज महसूस करूंगा: https://www.reddit.com/r/golang/comments/bwvyhe /proposal_a_builtin_go_error_check_function_try/eq22bqa?utm_source=share&utm_medium=web2x

@zeebo एक लाइन पर gofmt प्रारूप if err != nil { return ...., err } बनाना आसान होगा। संभवतः यह केवल इस विशिष्ट प्रकार के if पैटर्न के लिए होगा, सभी "लघु" if कथन नहीं?

उसी तर्ज पर, try के अदृश्य होने के बारे में चिंताएं थीं क्योंकि यह व्यावसायिक तर्क के समान ही है। हमारे पास ये सभी विकल्प हैं:

वर्तमान शैली:

a, b, c, ... err := BusinessLogic(...)
if err != nil {
   return ..., err
}

एक-पंक्ति if :

a, b, c, ... err := BusinessLogic(...)
if err != nil { return ..., err }

try एक अलग लाइन पर (!):

a, b, c, ... err := BusinessLogic(...)
try(err)

try जैसा कि प्रस्तावित है:

a, b, c := try(BusinessLogic(...))

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

@ मारवान-एट-वर्क मुझे यकीन नहीं है कि आप क्या प्रस्ताव दे रहे हैं कि उपकरण आपके लिए हैं। क्या आप सुझाव देते हैं कि वे किसी भी तरह त्रुटि प्रबंधन को छुपाते हैं?

@dpinela

@guybrand यह एक पूरी तरह से अलग प्रस्ताव की तरह लगता है; मुझे लगता है कि आपको इसे अपने मुद्दे के रूप में दर्ज करना चाहिए ताकि यह @griesemer के प्रस्ताव पर चर्चा करने पर ध्यान केंद्रित कर सके।

IMO मेरा प्रस्ताव केवल वाक्य रचना में भिन्न है, जिसका अर्थ है:

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

इसलिए मुख्य अंतर यह है कि क्या हम मूल फ़ंक्शन कॉल को try(func()) के साथ लपेट रहे हैं जो हमेशा कॉल को jnz करने के लिए अंतिम संस्करण का विश्लेषण करेगा या ऐसा करने के लिए वास्तविक वापसी मान का उपयोग करेगा।

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

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

@griesemer

मुझे यकीन नहीं है कि आप क्या प्रस्तावित कर रहे हैं कि उपकरण आपके लिए काम करते हैं। क्या आप सुझाव देते हैं कि वे किसी भी तरह त्रुटि प्रबंधन को छुपाते हैं?

बिल्कुल विपरीत: मैं सुझाव दे रहा हूं कि gopls वैकल्पिक रूप से आपके लिए त्रुटि प्रबंधन बॉयलरप्लेट लिख सकता है।

जैसा कि आपने अपनी पिछली टिप्पणी में उल्लेख किया है:

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

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

उदाहरण के लिए:

// user begins to write this function: 
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  return bts, nil
}

फिर उपयोगकर्ता टूल को ट्रिगर करता है, शायद केवल फ़ाइल को सहेजकर (इसी तरह gofmt/goimports आमतौर पर कैसे काम करता है) और gopls इस फ़ंक्शन को देखेंगे, इसके रिटर्न हस्ताक्षर का विश्लेषण करेंगे और कोड को इस तरह बढ़ाएंगे:

// user has triggered the tool (by saving the file, or code action)
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  return bts, nil
}

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

टूल को कैसे पता चलेगा कि मैं err को बाद में फ़ंक्शन में जल्दी लौटने के बजाय संभालना चाहता हूं? यद्यपि दुर्लभ, लेकिन कोड मैंने फिर भी लिखा है।

मुझे खेद है कि अगर इसे पहले लाया गया है, लेकिन मुझे इसका कोई उल्लेख नहीं मिला।

try(DoSomething()) मुझे अच्छी तरह से पढ़ता है, और समझ में आता है: कोड कुछ करने की कोशिश कर रहा है। try(err) , OTOH, थोड़ा हटकर महसूस करता है, शब्दार्थ की दृष्टि से: कोई त्रुटि का प्रयास कैसे करता है? मेरे विचार से, कोई त्रुटि _test_ या _check_ कर सकता है, लेकिन _trying_ कोई सही नहीं लगता।

मुझे एहसास है कि स्थिरता के कारणों के लिए try(err) की अनुमति देना महत्वपूर्ण है: मुझे लगता है कि यह अजीब होगा यदि try(DoSomething()) ने काम किया, लेकिन err := DoSomething(); try(err) ने ऐसा नहीं किया। फिर भी, ऐसा लगता है कि try(err) पृष्ठ पर थोड़ा अजीब लग रहा है। मैं किसी भी अन्य अंतर्निहित कार्यों के बारे में नहीं सोच सकता जो इतनी आसानी से अजीब दिखने के लिए बनाया जा सकता है।

इस मामले में मेरे पास कोई ठोस सुझाव नहीं है, लेकिन फिर भी मैं यह अवलोकन करना चाहता था।

@griesemer धन्यवाद। दरअसल, प्रस्ताव केवल return के लिए होना था, लेकिन मुझे संदेह है कि किसी एक कथन को एक पंक्ति होने की अनुमति देना अच्छा होगा। उदाहरण के लिए एक परीक्षण में, परीक्षण पुस्तकालय में कोई बदलाव नहीं किया जा सकता है

if err != nil { t.Fatal(err) }

पहली और आखिरी पंक्ति सबसे स्पष्ट (मेरे लिए) प्रतीत होती है, खासकर एक बार जब किसी को यह पहचानने के लिए प्रयोग किया जाता है कि यह क्या है। अंतिम पंक्ति के साथ, एक त्रुटि के लिए स्पष्ट रूप से जाँच की जाती है, लेकिन चूंकि यह (आमतौर पर) मुख्य क्रिया नहीं है, यह पृष्ठभूमि में थोड़ा अधिक है।

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

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

मैंने यह नहीं देखा कि डिज़ाइन दस्तावेज़ से इस प्रश्न का उत्तर कैसे दिया जाए। यह कोड क्या करता है:

func foo() (err error) {
    src := try(getReader())
    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }
        try(err)
        println(n)
    }
    return nil
}

मेरी समझ यह है कि यह desugar होगा

func foo() (err error) {
    tsrc, te := getReader()
    if err != nil {
        err = te
        return
    }
    src := tsrc

    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }

        terr := err
        if terr != nil {
            err = terr
            return
        }

        println(n)
    }
    return nil
}

जो संकलित करने में विफल रहता है क्योंकि err नग्न वापसी के दौरान छायांकित होता है। क्या यह संकलित नहीं होगा? यदि ऐसा है, तो यह एक बहुत ही सूक्ष्म विफलता है, और ऐसा होने की संभावना बहुत कम है। यदि नहीं, तो कुछ चीनी से ज्यादा चल रहा है।

@ मारवान-एट-वर्क

जैसा कि आपने अपनी पिछली टिप्पणी में उल्लेख किया है:

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

तो समस्या का दिल यह है कि प्रोग्रामर बहुत सारे बॉयलरप्लेट कोड लिखना समाप्त कर देता है। तो मसला लिखने का है, पढ़ने का नहीं।

मुझे लगता है कि यह वास्तव में दूसरा रास्ता है - मेरे लिए बॉयलरप्लेट को संभालने वाली वर्तमान त्रुटि के साथ सबसे बड़ी झुंझलाहट इसे टाइप करने के लिए इतना अधिक नहीं है, बल्कि यह स्क्रीन पर लंबवत रूप से फ़ंक्शन के खुश पथ को कैसे बिखेरता है, जिससे इसे समझना कठिन हो जाता है एक नज़र। प्रभाव विशेष रूप से I/O-भारी कोड में उच्चारित होता है, जहां आमतौर पर हर दो ऑपरेशन के बीच बॉयलरप्लेट का एक ब्लॉक होता है। यहां तक ​​​​कि CopyFile का एक सरलीकृत संस्करण ~ 20 लाइनें लेता है, भले ही यह वास्तव में केवल पांच चरण करता है: ओपन सोर्स, डिफर क्लोज सोर्स, ओपन डेस्टिनेशन, कॉपी सोर्स -> डेस्टिनेशन, क्लोज डेस्टिनेशन।

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

मुझे अलग लाइन पर try पसंद है।
और मुझे आशा है कि यह स्वतंत्र रूप से handler func निर्दिष्ट कर सकता है।

func try(error, optional func(error)error)

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    try(err)

    handle := func(err error) error {
        tx.Rollback()
        return err
    }

    var res int64
    _, err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(err, handle)

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(err, handle)

    return tx.Commit()
}

@zeebo : मैंने जो उदाहरण दिए हैं वे 1:1 अनुवाद हैं। पहला (पारंपरिक if ) त्रुटि को संभाल नहीं पाया, और इसलिए दूसरों ने नहीं किया। यदि पहले त्रुटि को संभाला जाता है, और यदि यह एकमात्र स्थान है जहां किसी फ़ंक्शन में त्रुटि की जांच की जाती है, तो पहला उदाहरण ( if का उपयोग करके) कोड लिखने का उपयुक्त विकल्प हो सकता है। यदि कई त्रुटि जांच हैं, जिनमें से सभी एक ही त्रुटि प्रबंधन (रैपिंग) का उपयोग करते हैं, तो कहें क्योंकि वे सभी वर्तमान फ़ंक्शन के बारे में जानकारी जोड़ते हैं, कोई भी एक ही स्थान पर त्रुटियों को संभालने के लिए defer कथन का उपयोग कर सकता है। वैकल्पिक रूप से, कोई व्यक्ति if को try में फिर से लिख सकता है (या उन्हें अकेला छोड़ दें)। यदि जांच करने के लिए कई त्रुटियां हैं, और वे सभी त्रुटियों को अलग तरह से संभालते हैं (जो एक संकेत हो सकता है कि फ़ंक्शन की चिंता बहुत व्यापक है और इसे विभाजित करने की आवश्यकता हो सकती है), if का उपयोग करना है जाने के लिए रास्ता। हां, एक ही काम करने के एक से अधिक तरीके हैं, और सही चुनाव कोड के साथ-साथ व्यक्तिगत स्वाद पर भी निर्भर करता है। जबकि हम "एक काम करने का एक तरीका" के लिए गो में प्रयास करते हैं, यह निश्चित रूप से पहले से ही नहीं है, खासकर सामान्य निर्माणों के लिए। उदाहरण के लिए, जब if - else - if अनुक्रम बहुत लंबा हो जाता है, तो कभी-कभी switch अधिक उपयुक्त हो सकता है। कभी-कभी एक परिवर्तनीय घोषणा var x int x := 0 से बेहतर इरादा व्यक्त करती है, और आगे भी (हालांकि हर कोई इस बारे में खुश नहीं है)।

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

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

यदि ओवररचिंग फ़ंक्शन का अंतिम रिटर्न प्रकार त्रुटि प्रकार का नहीं है, तो क्या हम घबरा सकते हैं?

यह बिल्टिन को अधिक बहुमुखी बना देगा (जैसे #32219 में मेरी चिंता को संतुष्ट करना)

@pjebs इस पर विचार किया गया है और इसके खिलाफ फैसला किया गया है। कृपया विस्तृत डिज़ाइन दस्तावेज़ पढ़ें (जो इस विषय पर आपकी समस्या को स्पष्ट रूप से संदर्भित करता है)।

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

func doSomething() (error, error, error, error, error) {
   ...
}

try(try(try(try(try(doSomething)))))

डिज़ाइन कहता है कि आपने त्रुटि के साथ लौटने के बजाय panic का उपयोग करके एक्सप्लोर किया।

मैं एक सूक्ष्म अंतर पर प्रकाश डाल रहा हूं:

ठीक वही करें जो आपके वर्तमान प्रस्ताव में कहा गया है, सिवाय उस प्रतिबंध को हटाने के कि ओवररचिंग फ़ंक्शन का अंतिम रिटर्न प्रकार होना चाहिए error ।

यदि इसमें error => पैनिक का अंतिम रिटर्न प्रकार नहीं है
यदि पैकेज स्तर परिवर्तनीय घोषणाओं के लिए प्रयास का उपयोग कर रहे हैं => आतंक ( MustXXX( ) सम्मेलन की आवश्यकता को हटा देता है)

यूनिट परीक्षणों के लिए, एक मामूली भाषा परिवर्तन।

@mattn , मुझे अत्यधिक संदेह है कि किसी भी सांकेतिक संख्या में लोग इस तरह कोड लिखेंगे।

@pjebs , वह शब्दार्थ - घबराहट अगर वर्तमान फ़ंक्शन में कोई त्रुटि परिणाम नहीं है - ठीक वही है जो डिज़ाइन डॉक्टर https://github.com/golang/proposal/blob/master/design/32437-try-builtin में चर्चा कर रहा है। एमडी # चर्चा।

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

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

@pjebs वह _exactly_ है जिसे हमने पूर्व प्रस्ताव में माना था (विस्तृत दस्तावेज़ देखें, डिज़ाइन पुनरावृत्तियों पर अनुभाग, चौथा अनुच्छेद):

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

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

@griesemer पुनर्लेखन के बारे में स्पष्टीकरण के लिए धन्यवाद। मुझे खुशी है कि यह संकलित होगा।

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

त्रुटियों को अलग तरीके से संभालने के बारे में, मैं असहमत हूं कि यह एक संकेत है कि फ़ंक्शन की चिंता बहुत व्यापक है। मैं टिप्पणियों से दावा किए गए वास्तविक कोड के कुछ उदाहरणों का अनुवाद कर रहा हूं और उन्हें अपनी मूल टिप्पणी के नीचे एक ड्रॉपडाउन में रख रहा हूं, और उदाहरण https://github.com/golang/go/issues/32437#issuecomment में - 499007288 मुझे लगता है कि एक सामान्य मामले को अच्छी तरह से प्रदर्शित करता है:

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

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

मुझे लगता है कि यह एक संकेत भी है कि defer wrap(&err, "message: %v", err) बग कितने सूक्ष्म थे और कैसे वे अनुभवी गो प्रोग्रामर को भी ट्रिप कर देते थे।

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

@griesemer क्षमा करें, मैंने एक अलग खंड पढ़ा जिसमें घबराहट पर चर्चा हुई और खतरों की चर्चा नहीं देखी गई।

@zeebo इस उदाहरण के लिए धन्यवाद। ऐसा लगता है कि इस मामले में if कथन का उपयोग करना बिल्कुल सही विकल्प है। लेकिन बिंदु लिया गया है, अगर को वन-लाइनर्स में स्वरूपित करना इसे थोड़ा सा सुव्यवस्थित कर सकता है।

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

file := try(os.Open("my_file.txt"), nil)

क्या होगा यदि हैंडलर प्रदान किया गया है लेकिन शून्य है? घबराहट की कोशिश करनी चाहिए या इसे एक अनुपस्थित त्रुटि हैंडलर के रूप में मानना ​​​​चाहिए?

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

क्या होगा यदि हैंडलर को गैर-शून्य त्रुटि के साथ बुलाया जाता है और फिर शून्य परिणाम देता है? क्या इसका मतलब यह है कि त्रुटि "रद्द" है? या संलग्न कार्य शून्य त्रुटि के साथ वापस आना चाहिए?

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

func getOrCreateObject(obj *object) error {
    defaultObjectHandler := func(err error) error {
        if err == ObjectDoesNotExistErr {
            *obj = object{}
            return nil
        }
        return fmt.Errorf("getting or creating object: %v", err)
    }

    *obj = try(db.getObject(), defaultObjectHandler)
}

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

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

एक बोनस के रूप में, मुझे लगता है कि त्रुटि हैंडलर की आवश्यकता भी गहराई से नेस्टेड try s को हतोत्साहित करती है क्योंकि वे कम संक्षिप्त हैं। कुछ लोग इसे नकारात्मक पक्ष के रूप में देख सकते हैं, लेकिन मुझे लगता है कि यह एक लाभ है।

@velovix मुझे यह विचार पसंद है, लेकिन त्रुटि-हैंडलर की आवश्यकता क्यों है? क्या यह डिफ़ॉल्ट रूप से nil नहीं हो सकता? हमें "दृश्य सुराग" की आवश्यकता क्यों है?

@griesemer क्या होगा यदि @velovix विचार अपनाया गया था, लेकिन builtin के साथ एक पूर्वनिर्धारित फ़ंक्शन शामिल है जो गलती को घबराहट में परिवर्तित करता है और हम आवश्यकता को हटा देते हैं कि ओवर-आर्किंग फ़ंक्शन में त्रुटि वापसी मान है?

विचार यह है कि, यदि ओवररचिंग फ़ंक्शन त्रुटि वापस नहीं करता है, तो त्रुटि-हैंडलर के बिना try का उपयोग करना एक संकलन-समय त्रुटि है।

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

@pjebs

त्रुटि-हैंडलर की आवश्यकता क्यों है? क्या यह डिफ़ॉल्ट रूप से शून्य नहीं हो सकता? हमें "दृश्य सुराग" की आवश्यकता क्यों है?

यह उन चिंताओं को दूर करने के लिए है जो

1. try प्रस्ताव जैसा कि अब है, लोगों को उनकी त्रुटियों का संदर्भ प्रदान करने से हतोत्साहित कर सकता है क्योंकि ऐसा करना इतना सीधा नहीं है।

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

1. मूल प्रस्ताव दस्तावेज़ से एक चिंता। मैंने इसे अपनी पहली टिप्पणी में उद्धृत किया:

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

एक स्पष्ट nil पास करने से त्रुटि को ठीक से संभालना भूलना अधिक कठिन हो जाता है। आपको स्पष्ट रूप से एक तर्क छोड़कर त्रुटि को संभालने के बजाय स्पष्ट रूप से ऐसा करने का निर्णय लेना होगा।

सशर्त वापसी के बारे में आगे सोचते हुए संक्षेप में https://github.com/golang/go/issues/32437#issuecomment -498947603 पर उल्लेख किया गया है।
ऐसा लगता है
return if f, err := os.Open("/my/file/path"); err != nil
गो के मौजूदा if दिखने के तरीके के साथ अधिक अनुपालन होगा।

यदि हम return if कथन के लिए एक नियम जोड़ते हैं कि
जब अंतिम शर्त अभिव्यक्ति (जैसे err != nil ) मौजूद नहीं है,और return if कथन में घोषणा का अंतिम चर error प्रकार का है,तो अंतिम चर का मान स्वतः ही nil के साथ अंतर्निहित स्थिति के रूप में तुलना कर दिया जाएगा।

फिर return if कथन को संक्षिप्त किया जा सकता है:
return if f, err := os.Open("my/file/path")

जो सिग्नल-शोर अनुपात के बहुत करीब है जो try प्रदान करता है।
अगर हम return if को try में बदलते हैं, तो यह बन जाता है
try f, err := os.Open("my/file/path")
यह फिर से इस धागे में try की अन्य प्रस्तावित विविधताओं के समान हो जाता है, कम से कम वाक्य-विन्यास के रूप में।
व्यक्तिगत रूप से, मैं अभी भी इस मामले में return if से अधिक try पसंद करता हूं क्योंकि यह किसी फ़ंक्शन के निकास बिंदुओं को बहुत स्पष्ट बनाता है। उदाहरण के लिए, डिबगिंग करते समय मैं अक्सर एक बड़े फ़ंक्शन के सभी निकास बिंदुओं की पहचान करने के लिए संपादक के भीतर कीवर्ड return को हाइलाइट करता हूं।

दुर्भाग्य से, ऐसा लगता है कि डीबग लॉगिंग डालने की असुविधा के साथ पर्याप्त मदद नहीं मिलती है।
जब तक हम return if के लिए return if body ब्लॉक की अनुमति नहीं देते, जैसे
मूल:

        return if f, err := os.Open("my/path") 

डिबगिंग करते समय:

-       return if f, err := os.Open("my/path") 
+       return if f, err := os.Open("my/path") {
+               fmt.Printf("DEBUG: os.Open: %s\n", err)
+       }

return if के बॉडी ब्लॉक का अर्थ स्पष्ट है, मुझे लगता है। इसे defer से पहले निष्पादित किया जाएगा और वापस लौटाया जाएगा।

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

@velovix हमें दूसरे तर्क के रूप में एक स्पष्ट हैंडलर फ़ंक्शन के साथ try का विचार काफी पसंद आया। लेकिन ऐसे बहुत से प्रश्न थे जिनके स्पष्ट उत्तर नहीं थे, जैसा कि डिज़ाइन दस्तावेज़ बताता है। आपने उनमें से कुछ का उत्तर इस प्रकार दिया है जो आपको उचित लगे। यह काफी संभावना है (और यह गो टीम के अंदर हमारा अनुभव था), कि कोई और सोचता है कि सही उत्तर काफी अलग है। उदाहरण के लिए, आप कह रहे हैं कि हैंडलर तर्क हमेशा प्रदान किया जाना चाहिए, लेकिन यह nil हो सकता है, यह स्पष्ट करने के लिए कि हम त्रुटि को संभालने की परवाह नहीं करते हैं। अब क्या होता है यदि कोई फ़ंक्शन मान प्रदान करता है ( nil शाब्दिक नहीं), और वह फ़ंक्शन मान (एक चर में संग्रहीत) शून्य होता है? स्पष्ट nil मान के अनुरूप, किसी हैंडलिंग की आवश्यकता नहीं है। लेकिन अन्य लोग तर्क दे सकते हैं कि यह कोड में एक बग है। या, वैकल्पिक रूप से कोई भी शून्य-मूल्यवान हैंडलर तर्कों की अनुमति दे सकता है, लेकिन फिर एक फ़ंक्शन कुछ मामलों में असंगत रूप से हैंडलर त्रुटियों को कर सकता है, न कि दूसरों में, और यह कोड से स्पष्ट रूप से स्पष्ट नहीं है, क्योंकि ऐसा प्रतीत होता है जैसे एक हैंडलर हमेशा मौजूद होता है . एक और तर्क यह था कि त्रुटि हैंडलर की शीर्ष-स्तरीय घोषणा करना बेहतर है क्योंकि इससे यह स्पष्ट हो जाता है कि फ़ंक्शन त्रुटियों को संभालता है। इसलिए defer । शायद और भी है।

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

@griesemer - IIUC, आप कह रहे हैं कि कॉलसाइट-निर्भर त्रुटि संदर्भों के लिए, वर्तमान यदि कथन ठीक है। जबकि, यह नया try फ़ंक्शन उन मामलों के लिए उपयोगी है जहां एक ही स्थान पर एकाधिक त्रुटियों को संभालना उपयोगी है।

मेरा मानना ​​​​है कि चिंता यह थी कि, कुछ मामलों के लिए केवल if err != nil { return err} करना ठीक हो सकता है, आमतौर पर लौटने से पहले त्रुटि को सजाने की सिफारिश की जाती है। और यह प्रस्ताव पिछले को संबोधित करता प्रतीत होता है और बाद के लिए बहुत कुछ नहीं करता है। जिसका अनिवार्य रूप से मतलब है कि लोगों को आसान-वापसी पैटर्न का उपयोग करने के लिए प्रोत्साहित किया जाएगा।

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

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

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

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

मुझे लगता है कि हम एक कैच फंक्शन भी जोड़ सकते हैं, जो एक अच्छी जोड़ी होगी, इसलिए:

func a() int {
  x := randInt()
  // let's assume that this is what recruiters should "fix" for us
  // or this happens in 3rd-party package.
  if x % 1337 != 0 {
    panic("not l33t enough")
  }
  return x
}

func b() error {
  // if a() panics, then x = 0, err = error{"not l33t enough"}
  x, err := catch(a())
  if err != nil {
    return err
  }
  sendSomewhereElse(x)
  return nil
}

// which could be simplified even further

func c() error {
  x := try(catch(a()))
  sendSomewhereElse(x)
  return nil
}

इस उदाहरण में, catch() recover() एक आतंक और return ..., panicValue होगा।
बेशक, हमारे पास एक स्पष्ट कोने का मामला है जिसमें हमारे पास एक func है, जो एक त्रुटि भी देता है। इस मामले में मुझे लगता है कि केवल पास-थ्रू त्रुटि मान के लिए सुविधाजनक होगा।

इसलिए, मूल रूप से, आप कैच () का उपयोग वास्तव में पुनर्प्राप्त () पैनिक के लिए कर सकते हैं और उन्हें त्रुटियों में बदल सकते हैं।
यह मेरे लिए काफी मज़ेदार लग रहा है, 'क्योंकि गो में वास्तव में अपवाद नहीं हैं, लेकिन इस मामले में हमारे पास बहुत साफ-सुथरा प्रयास () - कैच () पैटर्न है, जो आपके पूरे कोडबेस को जावा जैसी किसी चीज़ के साथ नहीं उड़ाएगा ( catch(Throwable) मेन + throws LiterallyAnything में)। आप किसी के आतंक को आसानी से संसाधित कर सकते हैं जैसे कि वे सामान्य त्रुटियां थीं। मेरे पास वर्तमान में मेरे वर्तमान प्रोजेक्ट में गो में लगभग 6mln+ LoC है, और मुझे लगता है कि यह कम से कम मेरे लिए चीजों को सरल करेगा।

@griesemer चर्चा के पुनर्कथन के लिए धन्यवाद।

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

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

उदाहरण के लिए:

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

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

अन्य क्या चिंताएँ थीं? मुझे पूरा यकीन है कि उन सभी का उत्तर उचित तरीके से समान रूप से दिया जा सकता है।

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

@griesemer

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

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

एक और तर्क यह था कि त्रुटि हैंडलर की शीर्ष-स्तरीय घोषणा करना बेहतर है क्योंकि इससे यह स्पष्ट हो जाता है कि फ़ंक्शन त्रुटियों को संभालता है। इसलिए defer ।

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

क्या इसे कोष्ठक के बिना काम करना संभव है?

यानी कुछ ऐसा:
a := try func(some)

@Cyberax - जैसा कि पहले ही ऊपर उल्लेख किया गया है, यह बहुत आवश्यक है कि आप पोस्ट करने से पहले डिज़ाइन दस्तावेज़ को ध्यान से पढ़ें। चूंकि यह एक उच्च-ट्रैफ़िक मुद्दा है, इसलिए बहुत से लोगों ने सदस्यता ली है।

डॉक्टर ऑपरेटरों बनाम कार्यों पर विस्तार से चर्चा करता है।

मुझे यह अगस्त संस्करण की तुलना में बहुत अधिक पसंद है।

मुझे लगता है कि अधिकांश नकारात्मक प्रतिक्रिया, जो return कीवर्ड के बिना रिटर्न के बिल्कुल विपरीत नहीं है, को दो बिंदुओं में संक्षेपित किया जा सकता है:

1. लोगों को नामित परिणाम पैरामीटर पसंद नहीं हैं, जो ज्यादातर मामलों में आवश्यक हो जाते हैं
2. यह त्रुटियों के लिए विस्तृत संदर्भ जोड़ने को हतोत्साहित करता है

उदाहरण के लिए देखें:

• https://github.com/golang/go/issues/32437#issuecomment -498937169
• https://github.com/golang/go/issues/32437#issuecomment -498967099
• https://github.com/golang/go/issues/32437#issuecomment -499194787
• https://github.com/golang/go/issues/32437#issuecomment -499309304

उन दो आपत्तियों का खंडन क्रमशः है:

1. "हमने तय किया कि [नामांकित परिणाम पैरामीटर] ठीक थे"
2. "कोई भी आपको try का उपयोग नहीं करने वाला है" / यह 100% मामलों के लिए उपयुक्त नहीं होगा

मेरे पास वास्तव में 1 के बारे में कहने के लिए कुछ नहीं है (मैं इसके बारे में दृढ़ता से महसूस नहीं करता)। लेकिन 2 के बारे में मैं ध्यान दूंगा कि अगस्त प्रस्ताव में यह समस्या नहीं थी, अधिकांश काउंटर प्रस्तावों में भी यह समस्या नहीं है।

विशेष रूप से न तो tryf प्रति-प्रस्ताव (जिसे इस सूत्र में दो बार स्वतंत्र रूप से पोस्ट किया गया है) और न ही try(X, handlefn) प्रति-प्रस्ताव (जो कि डिज़ाइन पुनरावृत्तियों का हिस्सा था) में यह समस्या थी।

मुझे लगता है कि यह तर्क देना कठिन है कि try , जैसा कि यह लोगों को प्रासंगिक संदर्भ के साथ सजाने की त्रुटियों से और एकल सामान्य प्रति-फ़ंक्शन त्रुटि सजावट की ओर धकेल देगा।

इन कारणों से मुझे लगता है कि इस मुद्दे को हल करने की कोशिश करना उचित है और मैं एक संभावित समाधान का प्रस्ताव देना चाहता हूं:

1. वर्तमान में defer का पैरामीटर केवल एक फ़ंक्शन या विधि कॉल हो सकता है। defer को एक फ़ंक्शन नाम या एक फ़ंक्शन शाब्दिक होने की अनुमति दें, अर्थात

defer func(...) {...}
defer packageName.functionName

1. जब घबराहट या आस्थगित वापसी इस प्रकार के आस्थगन का सामना करती है, तो वे अपने सभी मापदंडों के लिए शून्य मान को पारित करने वाले फ़ंक्शन को कॉल करेंगे

2. try को एक से अधिक पैरामीटर होने दें

3. जब try नए प्रकार के defer का सामना करता है, तो यह फ़ंक्शन को त्रुटि मान के लिए एक पॉइंटर पास करने वाले फ़ंक्शन को पहले पैरामीटर के रूप में कॉल करेगा, जिसके बाद सभी try के स्वयं के पैरामीटर होंगे, पहले वाले को छोड़कर।

उदाहरण के लिए, दिया गया:

func errorfn() error {
    return errors.New("an error")
}


func f(fail bool) {
    defer func(err *error, a, b, c int) {
        fmt.Printf("a=%d b=%d c=%d\n", a, b, c)
    }
    if fail {
        try(errorfn, 1, 2, 3)
    }
}

निम्नलिखित होगा:

f(false)        // prints "a=0 b=0 c=0"
f(true)         // prints "a=1 b=2 c=3"

https://github.com/golang/go/issues/32437#issuecomment -499309304 में @zeebo द्वारा कोड को फिर से लिखा जा सकता है:

func (c *Config) Build() error {
    defer func(err *error, msg string, args ...interface{}) {
        if *err == nil || msg == "" {
            return
        }
        *err = errors.WithMessagef(err, msg, args...)
    }
    pkgPath := try(c.load(), "load config dir")

    b := bytes.NewBuffer(nil)
    try(templates.ExecuteTemplate(b, "main", c), "execute main template")

    buf := try(format.Source(b.Bytes()), "format main template")

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)
    // ...
}

और ErrorHandlef को इस प्रकार परिभाषित करना:

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

fmt -स्टाइल प्रारूप स्ट्रिंग्स को मूल भाषा में खींचे बिना, सभी को tryf के बाद बहुत अधिक मांग वाला मुफ्त में देगा।

यह सुविधा पश्चगामी संगत है क्योंकि defer फ़ंक्शन अभिव्यक्तियों को इसके तर्क के रूप में अनुमति नहीं देता है। यह नए खोजशब्दों का परिचय नहीं देता है।
https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md में उल्लिखित परिवर्तनों के अलावा, इसे लागू करने के लिए जिन परिवर्तनों की आवश्यकता है, वे हैं:

1. पार्सर को नए प्रकार के विलंब के बारे में सिखाएं
2. यह जांचने के लिए टाइप चेकर बदलें कि किसी फ़ंक्शन के अंदर पैरामीटर (कॉल के बजाए) के रूप में फ़ंक्शन वाले सभी डिफर्स के समान हस्ताक्षर हैं
3. यह जाँचने के लिए टाइप चेकर बदलें कि try defer दिए गए कार्यों के हस्ताक्षर से मेल खाते हैं
4. उपयुक्त deferproc कॉल उत्पन्न करने के लिए बैकएंड (?) बदलें
5. अपने तर्कों को आस्थगित कॉल के तर्कों में कॉपी करने के लिए try के कार्यान्वयन को बदलें जब यह नए प्रकार के आस्थगित कॉल का सामना करता है।

check/handle ड्राफ्ट डिजाइन की जटिलताओं के बाद, मुझे यह बहुत सरल और व्यावहारिक प्रस्ताव भूमि देखकर सुखद आश्चर्य हुआ, हालांकि मैं निराश हूं कि इसके खिलाफ इतना धक्का-मुक्की हुई है।

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

कुछ विशिष्ट बिंदुओं के संबंध में:

1. प्रस्ताव के बारे में मुझे केवल एक चीज नापसंद है, जब defer का उपयोग किया जाता है, तो एक नामित त्रुटि वापसी पैरामीटर की आवश्यकता होती है, लेकिन यह कहते हुए कि, मैं किसी अन्य समाधान के बारे में नहीं सोच सकता, जो बाधाओं पर नहीं होगा जिस तरह से बाकी भाषा काम करती है। इसलिए मुझे लगता है कि अगर प्रस्ताव को स्वीकार कर लिया जाता है तो हमें इसे स्वीकार करना होगा।

2. यह अफ़सोस की बात है कि try उन कार्यों के लिए परीक्षण पैकेज के साथ अच्छा नहीं खेलता है जो त्रुटि मान नहीं लौटाते हैं। इसके लिए मेरा अपना पसंदीदा समाधान एक दूसरा बिल्ट-इन फ़ंक्शन (शायद ptry या must ) होना चाहिए जो एक गैर-शून्य त्रुटि का सामना करने पर लौटने के बजाय हमेशा घबराता है और इसलिए हो सकता है उपरोक्त कार्यों के साथ प्रयोग किया जाता है ( main सहित)। यद्यपि इस विचार को प्रस्ताव के वर्तमान पुनरावृत्ति में अस्वीकार कर दिया गया है, मुझे लगा कि यह एक 'निकट कॉल' था और इसलिए यह पुनर्विचार के योग्य हो सकता है।

3. मुझे लगता है कि लोगों के लिए यह जानना मुश्किल होगा कि go try(f) या defer try(f) क्या कर रहे थे और इसलिए उन्हें पूरी तरह से प्रतिबंधित करना सबसे अच्छा है।

4. मैं उन लोगों से सहमत हूं जो सोचते हैं कि मौजूदा त्रुटि प्रबंधन तकनीक कम वर्बोज़ दिखाई देगी यदि go fmt ने सिंगल लाइन if स्टेटमेंट को फिर से नहीं लिखा। व्यक्तिगत रूप से, मैं एक साधारण नियम पसंद करूंगा कि _any_ सिंगल स्टेटमेंट if के लिए इसकी अनुमति दी जाएगी चाहे वह त्रुटि प्रबंधन से संबंधित हो या नहीं। असल में मैं कभी यह समझने में सक्षम नहीं हूं कि सिंगल-लाइन फ़ंक्शंस लिखते समय वर्तमान में इसकी अनुमति क्यों नहीं है जहां घोषणा की अनुमति के रूप में शरीर को उसी पंक्ति पर रखा गया है।

सजाने की त्रुटियों के मामले में

func myfunc()( err error){
try(thing())
defer func(){
err = errors.Wrap(err,"more context")
}()
}

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

मुझे वास्तव में इसकी सादगी और "एक काम अच्छी तरह से करें" दृष्टिकोण पसंद है। मेरे GoAWK दुभाषिया में यह बहुत मददगार होगा - मेरे पास लगभग 100 if err != nil { return nil } संरचनाएँ हैं जो इसे सरल और सुव्यवस्थित करेंगी, और यह काफी छोटे कोडबेस में है।

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

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

मैं इस प्रस्ताव के पक्ष में हूं। यह पिछले प्रस्ताव के बारे में मेरे सबसे बड़े आरक्षण से बचाता है: handle के संबंध में defer की गैर-रूढ़िवादीता।

मैं दो पहलुओं का उल्लेख करना चाहता हूं जो मुझे नहीं लगता कि ऊपर प्रकाश डाला गया है।

सबसे पहले, हालांकि यह प्रस्ताव संदर्भ-विशिष्ट त्रुटि पाठ को त्रुटि में जोड़ना आसान नहीं बनाता है, यह _does_ त्रुटि में स्टैक फ़्रेम त्रुटि-अनुरेखण जानकारी जोड़ना आसान बनाता है: https://play.golang.org/p /YL1MoqR08E6

दूसरे, try यकीनन https://github.com/golang/go/issues/19642 में अंतर्निहित अधिकांश समस्याओं का उचित समाधान है। उस मुद्दे से एक उदाहरण लेने के लिए, आप हर बार सभी वापसी मूल्यों को लिखने से बचने के लिए try का उपयोग कर सकते हैं। लंबे नामों के साथ मूल्य संरचना प्रकारों को वापस करते समय यह संभावित रूप से उपयोगी होता है।

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    i := f.cached.locations[xx+0]
    j := f.cached.locations[xx+1]
    if j < i {
        try(errInvalidGlyphDataLength)
    }
    if j-i > maxGlyphDataLength {
        try(errUnsupportedGlyphDataLength)
    }
    buf, err = b.view(&f.src, int(i), int(j-i))
    return buf, i, j - i, err
}

मुझे यह प्रस्ताव भी पसंद है।

और मेरा एक निवेदन है।

make की तरह, क्या हम try को पैरामीटर की एक चर संख्या लेने की अनुमति दे सकते हैं

• कोशिश (एफ):
  ऊपरोक्त अनुसार।
  एक वापसी त्रुटि मान अनिवार्य है (अंतिम वापसी पैरामीटर के रूप में)।
  सबसे आम उपयोग मॉडल
• कोशिश करें (एफ, डोपैनिक बूल):
  ऊपर के रूप में, लेकिन अगर doPanic है, तो लौटने के बजाय घबराएं (गलती)।
  इस मोड में, वापसी त्रुटि मान आवश्यक नहीं है।
• कोशिश करें (एफ, एफएन):
  ऊपर के रूप में, लेकिन लौटने से पहले fn(err) पर कॉल करें।
  इस मोड में, वापसी त्रुटि मान आवश्यक नहीं है।

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

• हमेशा स्पष्ट - यह अनुमान लगाने की आवश्यकता नहीं है कि घबराना है या त्रुटि सेट करना है और वापस लौटना है
• संदर्भ-विशिष्ट हैंडलर का समर्थन करता है (लेकिन कोई हैंडलर श्रृंखला नहीं)
• उपयोग-मामलों का समर्थन करता है जहां कोई त्रुटि वापसी चर नहीं है
• (...) शब्दार्थ का समर्थन करता है

जबकि दोहराव if err !=nil { return ... err } निश्चित रूप से एक बदसूरत हकलाना है, मैं उनके साथ हूं
जो सोचते हैं कि try() प्रस्ताव पठनीयता पर बहुत कम है और कुछ हद तक अस्पष्ट है।
नामित रिटर्न का उपयोग भी समस्याग्रस्त है।

अगर इस तरह की सफाई की जरूरत है, तो try(err) के लिए वाक्यात्मक चीनी के रूप में क्यों नहीं
if err !=nil { return err } :

file, err := os.Open("file.go")
try(err)

के लिये

file, err := os.Open("file.go")
if err != nil {
   return err
}

और यदि एक से अधिक वापसी मूल्य हैं, तो try(err) return t1, ... tn, err . हो सकता है
जहां t1, ... tn अन्य वापसी मूल्यों के शून्य मान हैं।

यह सुझाव नामित वापसी मूल्यों की आवश्यकता को कम कर सकता है और हो सकता है,
मेरे विचार से, समझने में आसान और अधिक पठनीय।

इससे भी बेहतर, मुझे लगता है कि होगा:

file, try(err) := os.Open("file.go")

या और भी

file, err? := os.Open("file.go")

यह अंतिम पश्चगामी संगत है (? वर्तमान में पहचानकर्ताओं में अनुमति नहीं है)।

(यह सुझाव https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes से संबंधित है। लेकिन बार-बार आने वाले विषय के उदाहरण अलग लगते हैं क्योंकि यह उस चरण में था जब एक स्पष्ट हैंडल को छोड़ने के बजाय अभी भी चर्चा की जा रही थी। कि एक स्थगित करने के लिए।)

इस सावधान, दिलचस्प प्रस्ताव के लिए गो टीम को धन्यवाद।

@rogpeppe टिप्पणी अगर try स्टैक फ्रेम को ऑटो-जोड़ता है, मुझे नहीं, मैं संदर्भ जोड़ने को हतोत्साहित करने के साथ ठीक हूं।

@aarzilli - तो आपके प्रस्ताव के अनुसार, हर बार जब हम tryf को अतिरिक्त पैरामीटर देते हैं तो क्या एक स्थगित खंड अनिवार्य है?

क्या होता है अगर मैं

try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

और एक defer समारोह मत लिखो?

@agnivade

क्या होता है यदि मैं (...) करता हूं और एक defer फ़ंक्शन नहीं लिखता हूं?

टाइपचेक त्रुटि।

मेरी राय में, सभी वापसी मूल्यों को लिखने से बचने के लिए try का उपयोग करना वास्तव में इसके खिलाफ एक और हड़ताल है।

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    //...

मैं return nil, 0, 0, ErrNotFound लिखने से बचने की इच्छा को पूरी तरह से समझता हूं, लेकिन मैं इसे किसी अन्य तरीके से हल करना चाहता हूं।

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

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

return default(ErrNotFound)

कम से कम वह किसी तरह के तर्क के साथ पढ़ता है।

लेकिन आइए किसी अन्य समस्या को हल करने के लिए try का दुरुपयोग न करें।

@natefinch अगर मूल प्रस्ताव की तरह try बिल्टिन को $#$1 check #$ नाम दिया गया है, तो यह check(err) होगा जो काफी बेहतर पढ़ता है, आईएमओ।

इसे एक तरफ रखकर, मुझे नहीं पता कि try(err) लिखना वास्तव में एक दुरुपयोग है या नहीं। यह स्पष्ट रूप से परिभाषा से बाहर हो जाता है। लेकिन, दूसरी ओर, इसका अर्थ यह भी है कि यह कानूनी है:

a, b := try(1, f(), err)

मुझे लगता है कि try के साथ मेरी मुख्य समस्या यह है कि यह वास्तव में केवल एक panic है जो केवल एक स्तर ऊपर जाता है ... सिवाय इसके कि घबराहट के विपरीत, यह एक अभिव्यक्ति है, एक बयान नहीं है, इसलिए आप छुपा सकते हैं यह कहीं एक बयान के बीच में है। यह लगभग इसे घबराहट से भी बदतर बना देता है।

@natefinch यदि आप इसे एक आतंक की तरह अवधारणा करते हैं जो एक स्तर ऊपर जाता है और फिर अन्य चीजें करता है, तो यह बहुत गन्दा लगता है। हालाँकि, मैं इसे अलग तरह से मानता हूँ। गो में त्रुटियों को वापस करने वाले कार्य प्रभावी रूप से परिणाम लौटा रहे हैं, रस्ट की शब्दावली से शिथिल रूप से उधार लेने के लिए। try एक उपयोगिता है जो परिणाम को अनपैक करती है और या तो "त्रुटि परिणाम" लौटाती है यदि error != nil , या यदि error == nil है तो परिणाम के T भाग को अनपैक करें।

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

@ugorji आपके द्वारा प्रस्तावित try(f, bool) संस्करण #32219 से must जैसा लगता है।

@ugorji आपके द्वारा प्रस्तावित try(f, bool) संस्करण #32219 से must जैसा लगता है।

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

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

func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

@ugorji
मुझे लगता है कि try(f, bool) पर बूलियन पढ़ना मुश्किल और याद करने में आसान बना देगा। मुझे आपका प्रस्ताव पसंद है लेकिन पैनिक केस के लिए मुझे लगता है कि उपयोगकर्ताओं को यह लिखने के लिए छोड़ दिया जा सकता है कि आपके तीसरे बुलेट से हैंडलर के अंदर, उदाहरण के लिए try(f(), func(err error) { panic('at the disco'); }) , यह उपयोगकर्ताओं के लिए छिपे हुए try(f(), true) की तुलना में अधिक स्पष्ट बनाता है

@ugorji
मुझे लगता है कि try(f, bool) पर बूलियन पढ़ना मुश्किल और याद करने में आसान बना देगा। मुझे आपका प्रस्ताव पसंद है लेकिन पैनिक केस के लिए मुझे लगता है कि उपयोगकर्ताओं को यह लिखने के लिए छोड़ दिया जा सकता है कि आपके तीसरे बुलेट से हैंडलर के अंदर, उदाहरण के लिए try(f(), func(err error) { panic('at the disco'); }) , यह उपयोगकर्ताओं के लिए छिपे हुए try(f(), true) की तुलना में अधिक स्पष्ट बनाता है

आगे के विचार पर, मैं आपकी स्थिति और आपके तर्क से सहमत हूं, और यह अभी भी एक-लाइनर के रूप में सुरुचिपूर्ण दिखता है।

@ patrick-nyt अभी भी https://github.com/golang/go/issues/32437#issuecomment -499533464 में शून्य परीक्षण को ट्रिगर करने के लिए _असाइनमेंट सिंटैक्स_ का एक और प्रस्तावक है।

यह अवधारणा चेक/हैंडल प्रस्ताव के 13 अलग-अलग प्रतिक्रियाओं में प्रकट होती है
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

f, ?return := os.Open(...)
f, ?panic  := os.Open(...)

क्यों? क्योंकि यह गो 1 की तरह पढ़ता है, जबकि try() और check नहीं।

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md#draft -design

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

func CopyFile(src, dst string) error {
    var err error // Don't need a named return because err is explicitly named
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r, err := os.Open(src)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    w, err := os.Create(dst)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    _, err = io.Copy(w, r)

    return err
}

पीजीस्टोर उदाहरण:

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    err?

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    // tricky bit: this would not change the value of err 
    // but the deferred.Cond would still be triggered by err being set before
    deferred.Format(err, "insert table")?

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    deferred.Format(err, "insert table2")?

    return tx.Commit()
}

मुझे यह @jargv से पसंद है :

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

लेकिन तर्कों की संख्या के आधार पर try नाम को ओवरलोड करने के बजाय, मुझे लगता है कि एक और जादू बनाया जा सकता है, reterr या कुछ और कहें।

मैंने कुछ अक्सर उपयोग किए जाने वाले पैकेजों के माध्यम से ब्रीफ किया है, गो कोड की तलाश में है जो गलती से "पीड़ित" है लेकिन लिखित से पहले अच्छी तरह से सोचा जाना चाहिए, यह पता लगाने की कोशिश कर रहा है कि प्रस्तावित प्रयास() क्या "जादू" करेगा।
वर्तमान में, जब तक मैंने प्रस्ताव को गलत नहीं समझा, उनमें से कई (उदाहरण के लिए सुपर बेसिक एरर हैंडलिंग नहीं) को अधिक लाभ नहीं होगा, या उन्हें "पुरानी" त्रुटि प्रबंधन शैली के साथ रहना होगा।
नेट/http/request.go से उदाहरण:

func (r *Request) write(w io.Writer, usingProxy bool, extraHeaders Header, waitForContinue func() bool) (err error) {
`

trace := httptrace.ContextClientTrace(r.Context())
if trace != nil && trace.WroteRequest != nil {
    defer func() {
        trace.WroteRequest(httptrace.WroteRequestInfo{
            Err: err,
        })
    }()
}

// Find the target host. Prefer the Host: header, but if that
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
host := cleanHost(r.Host)
if host == "" {
    if r.URL == nil {
        return errMissingHost
    }
    host = cleanHost(r.URL.Host)
}

// According to RFC 6874, an HTTP client, proxy, or other
// intermediary must remove any IPv6 zone identifier attached
// to an outgoing URI.
host = removeZone(host)

ruri := r.URL.RequestURI()
if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
    ruri = r.URL.Scheme + "://" + host + ruri
} else if r.Method == "CONNECT" && r.URL.Path == "" {
    // CONNECT requests normally give just the host and port, not a full URL.
    ruri = host
    if r.URL.Opaque != "" {
        ruri = r.URL.Opaque
    }
}
if stringContainsCTLByte(ruri) {
    return errors.New("net/http: can't write control character in Request.URL")
}
// TODO: validate r.Method too? At least it's less likely to
// come from an attacker (more likely to be a constant in
// code).

// Wrap the writer in a bufio Writer if it's not already buffered.
// Don't always call NewWriter, as that forces a bytes.Buffer
// and other small bufio Writers to have a minimum 4k buffer
// size.
var bw *bufio.Writer
if _, ok := w.(io.ByteWriter); !ok {
    bw = bufio.NewWriter(w)
    w = bw
}

_, err = fmt.Fprintf(w, "%s %s HTTP/1.1\r\n", valueOrDefault(r.Method, "GET"), ruri)
if err != nil {
    return err
}

// Header lines
_, err = fmt.Fprintf(w, "Host: %s\r\n", host)
if err != nil {
    return err
}
if trace != nil && trace.WroteHeaderField != nil {
    trace.WroteHeaderField("Host", []string{host})
}

// Use the defaultUserAgent unless the Header contains one, which
// may be blank to not send the header.
userAgent := defaultUserAgent
if r.Header.has("User-Agent") {
    userAgent = r.Header.Get("User-Agent")
}
if userAgent != "" {
    _, err = fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)
    if err != nil {
        return err
    }
    if trace != nil && trace.WroteHeaderField != nil {
        trace.WroteHeaderField("User-Agent", []string{userAgent})
    }
}

// Process Body,ContentLength,Close,Trailer
tw, err := newTransferWriter(r)
if err != nil {
    return err
}
err = tw.writeHeader(w, trace)
if err != nil {
    return err
}

err = r.Header.writeSubset(w, reqWriteExcludeHeader, trace)
if err != nil {
    return err
}

if extraHeaders != nil {
    err = extraHeaders.write(w, trace)
    if err != nil {
        return err
    }
}

_, err = io.WriteString(w, "\r\n")
if err != nil {
    return err
}

if trace != nil && trace.WroteHeaders != nil {
    trace.WroteHeaders()
}

// Flush and wait for 100-continue if expected.
if waitForContinue != nil {
    if bw, ok := w.(*bufio.Writer); ok {
        err = bw.Flush()
        if err != nil {
            return err
        }
    }
    if trace != nil && trace.Wait100Continue != nil {
        trace.Wait100Continue()
    }
    if !waitForContinue() {
        r.closeBody()
        return nil
    }
}

if bw, ok := w.(*bufio.Writer); ok && tw.FlushHeaders {
    if err := bw.Flush(); err != nil {
        return err
    }
}

// Write body and trailer
err = tw.writeBody(w)
if err != nil {
    if tw.bodyReadError == err {
        err = requestBodyReadError{err}
    }
    return err
}

if bw != nil {
    return bw.Flush()
}
return nil

}
`

या जैसा कि pprof/profile/profile_test.go जैसे संपूर्ण परीक्षण में उपयोग किया जाता है:
`
func checkAggregation(prof *Profile, a *aggTest) त्रुटि {
// जांचें कि पंक्तियों के लिए नमूनों की कुल संख्या संरक्षित है।
कुल: = int64(0)

samples := make(map[string]bool)
for _, sample := range prof.Sample {
    tb := locationHash(sample)
    samples[tb] = true
    total += sample.Value[0]
}

if total != totalSamples {
    return fmt.Errorf("sample total %d, want %d", total, totalSamples)
}

// Check the number of unique sample locations
if a.rows != len(samples) {
    return fmt.Errorf("number of samples %d, want %d", len(samples), a.rows)
}

// Check that all mappings have the right detail flags.
for _, m := range prof.Mapping {
    if m.HasFunctions != a.function {
        return fmt.Errorf("unexpected mapping.HasFunctions %v, want %v", m.HasFunctions, a.function)
    }
    if m.HasFilenames != a.fileline {
        return fmt.Errorf("unexpected mapping.HasFilenames %v, want %v", m.HasFilenames, a.fileline)
    }
    if m.HasLineNumbers != a.fileline {
        return fmt.Errorf("unexpected mapping.HasLineNumbers %v, want %v", m.HasLineNumbers, a.fileline)
    }
    if m.HasInlineFrames != a.inlineFrame {
        return fmt.Errorf("unexpected mapping.HasInlineFrames %v, want %v", m.HasInlineFrames, a.inlineFrame)
    }
}

// Check that aggregation has removed finer resolution data.
for _, l := range prof.Location {
    if !a.inlineFrame && len(l.Line) > 1 {
        return fmt.Errorf("found %d lines on location %d, want 1", len(l.Line), l.ID)
    }

    for _, ln := range l.Line {
        if !a.fileline && (ln.Function.Filename != "" || ln.Line != 0) {
            return fmt.Errorf("found line %s:%d on location %d, want :0",
                ln.Function.Filename, ln.Line, l.ID)
        }
        if !a.function && (ln.Function.Name != "") {
            return fmt.Errorf(`found file %s location %d, want ""`,
                ln.Function.Name, l.ID)
        }
    }
}

return nil

}
`
ये दो उदाहरण हैं जिनके बारे में मैं सोच सकता हूं जिसमें कोई कहेगा: "मुझे एक बेहतर त्रुटि प्रबंधन विकल्प चाहिए"

क्या कोई यह प्रदर्शित कर सकता है कि try() का उपयोग करके ये कैसे सुधार करेंगे?

मैं ज्यादातर इस प्रस्ताव के पक्ष में हूं।

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

• परिणाम मापदंडों का दस्तावेज़ीकरण
• एक डिफर के अंदर परिणाम मान (आमतौर पर एक error ) में हेरफेर करना

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

किसी अंतर्निहित त्रुटि पैरामीटर के साथ फ़ंक्शन को कॉल करने के लिए defer का उपयोग करने दें।

तो अगर आपके पास कोई फ़ंक्शन है

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

फिर, एक फ़ंक्शन g में जहां अंतिम परिणाम पैरामीटर में error टाइप किया गया है (यानी, कोई भी फ़ंक्शन जहां try मेरा उपयोग किया जाता है), f पर कॉल करें निम्नानुसार स्थगित किया जा सकता है:

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

त्रुटि-स्थगित के शब्दार्थ हैं:

1. f के लिए स्थगित कॉल को f के अंतिम परिणाम पैरामीटर के साथ g f पहले इनपुट पैरामीटर के रूप में कहा जाता है
2. f केवल तभी कॉल किया जाता है जब वह त्रुटि शून्य न हो
3. f का परिणाम g . के अंतिम परिणाम पैरामीटर को सौंपा गया है

तो पुराने एरर-हैंडलिंग डिज़ाइन डॉक से एक उदाहरण का उपयोग करने के लिए, एरर-डेफर का उपयोग करके और कोशिश करें, हम कर सकते हैं

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

यहां बताया गया है कि HandleErrorf कैसे काम करेगा:

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

func handleErrorf(err error, format string, args ...interface{}) error {
    return fmt.Errorf(format+": %v", append(args, err)...)
}

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

func(error, ...error) error

यह कहना उचित लगता है कि इस मामले को गैर-त्रुटि-स्थगित तरीके से संभाला जाता है (और यह पिछड़ी संगतता को बरकरार रखता है)।

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

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

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) (_ []*File, err error) {
    files := make([]*file, len(keys))

    defer func() {
        if err != nil {
            // Return any successfully retrieved files.
            for _, f := range files {
                if f != nil {
                    c.put(f)
                }
            }
        }
    }()

    // ...
}

त्रुटि-स्थगित के साथ, यह बन जाता है:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) ([]*File, error) {
    files := make([]*file, len(keys))

    defer func(err error) error {
        // Return any successfully retrieved files.
        for _, f := range files {
            if f != nil {
                c.put(f)
            }
        }
        return err
    }()

    // ...
}

@beoran आपकी टिप्पणी के बारे में कि हमें जेनरिक की प्रतीक्षा करनी चाहिए। जेनरिक यहां मदद नहीं करेगा - कृपया अक्सर पूछे जाने वाले प्रश्न पढ़ें।

@velovix के 2-तर्क try के डिफ़ॉल्ट व्यवहार पर आपके सुझावों के संबंध में: जैसा कि मैंने पहले कहा था, स्पष्ट रूप से उचित विकल्प क्या है इसका आपका विचार किसी और का दुःस्वप्न है।

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

(उस मामले के लिए मुझे एक हैंडलर रखना पसंद है। यह हमारे पहले के प्रस्तावों में से एक है। और अगर हम try को अपनाते हैं, तो हम अभी भी try की ओर एक हैंडलर के साथ आगे बढ़ सकते हैं। -संगत तरीका - कम से कम अगर हैंडलर वैकल्पिक है। लेकिन चलिए एक बार में एक कदम उठाते हैं।)

@arzilli आपके सुझाव के लिए धन्यवाद।

जब तक सजाने की त्रुटियां वैकल्पिक हैं, लोग इसे नहीं करने की ओर झुकेंगे (यह अतिरिक्त काम है)। मेरी टिप्पणी यहाँ भी देखें।

इसलिए, मुझे नहीं लगता कि प्रस्तावित try _discourages_ लोगों को सजाने की त्रुटियों से (वे पहले से ही उपरोक्त कारण से if के साथ भी निराश हैं); यह है कि try इसे _प्रोत्साहित नहीं करता है।

(इसे प्रोत्साहित करने का एक तरीका यह है कि इसे try में बाँध दिया जाए: कोई केवल try का उपयोग कर सकता है यदि कोई त्रुटि को सजाता है, या स्पष्ट रूप से ऑप्ट आउट करता है।)

लेकिन आपके सुझावों पर वापस: मुझे लगता है कि आप यहां बहुत अधिक मशीनरी पेश कर रहे हैं। defer try लिए इसे बेहतर काम करने के लिए कुछ ऐसा नहीं है जिस पर हम विचार करना चाहेंगे जब तक कि defer परिवर्तन अधिक सामान्य तरीके से फायदेमंद न हों। साथ ही, आपका सुझाव defer को try के साथ जोड़ता है और इस प्रकार उन दोनों तंत्रों को कम ऑर्थोगोनल बनाता है; कुछ हम बचना चाहेंगे।

लेकिन इससे भी महत्वपूर्ण बात, मुझे संदेह है कि आप सभी को defer लिखने के लिए मजबूर करना चाहेंगे ताकि वे try का उपयोग कर सकें। लेकिन ऐसा किए बिना, हम एक वर्ग में वापस आ गए हैं: लोग त्रुटियों को न सजाने की ओर झुकेंगे।

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

ज़रूर, शायद एक बहु-चरणीय दृष्टिकोण जाने का रास्ता है। यदि हम भविष्य में एक वैकल्पिक हैंडलर तर्क जोड़ते हैं, तो टूलिंग को लेखक को errcheck टूल के समान भावना से हैंडल न किए गए try के बारे में चेतावनी देने के लिए बनाया जा सकता है। भले ही, मैं आपकी प्रतिक्रिया की सराहना करता हूं!

@alanfo आपकी सकारात्मक प्रतिक्रिया के लिए धन्यवाद।

आपके द्वारा उठाए गए बिंदुओं के संबंध में:

1) यदि try के साथ एकमात्र मुद्दा यह है कि किसी को एक त्रुटि वापसी का नाम देना होगा ताकि हम defer के माध्यम से एक त्रुटि को सजा सकें, मुझे लगता है कि हम अच्छे हैं। यदि परिणाम का नामकरण एक वास्तविक समस्या है, तो हम इसका समाधान कर सकते हैं। एक साधारण तंत्र जिसके बारे में मैं सोच सकता हूं वह एक पूर्व घोषित चर होगा जो एक त्रुटि परिणाम के लिए उपनाम है (इसे उस त्रुटि के रूप में सोचें जिसने सबसे हालिया try को ट्रिगर किया)। बेहतर विचार हो सकते हैं। हमने इसका प्रस्ताव नहीं दिया क्योंकि भाषा में पहले से ही एक तंत्र है, जो परिणाम को नाम देना है।
2) try और परीक्षण: इसे संबोधित किया जा सकता है और काम करने के लिए बनाया जा सकता है। विस्तृत दस्तावेज़ देखें।
3) इसे विस्तृत दस्तावेज़ में स्पष्ट रूप से संबोधित किया गया है।
4) मान्यता प्राप्त है।

@benhoyt आपकी सकारात्मक प्रतिक्रिया के लिए धन्यवाद।

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

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

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

@ugorji आपकी सकारात्मक प्रतिक्रिया के लिए धन्यवाद।

अतिरिक्त तर्क लेने के लिए try को बढ़ाया जा सकता है। हमारी प्राथमिकता केवल हस्ताक्षर func (error) error के साथ एक समारोह लेना होगा। यदि आप घबराना चाहते हैं, तो एक-पंक्ति सहायक फ़ंक्शन प्रदान करना आसान है:

func doPanic(err error) error { panic(err) }

try के डिज़ाइन को सरल रखना बेहतर है।

@ पैट्रिक-नाइट आप क्या सुझाव दे रहे हैं:

file, err := os.Open("file.go")
try(err)

मौजूदा प्रस्ताव से संभव होगा।

@dpinela , @ugorji कृपया must बनाम try के विषय पर डिज़ाइन दस्तावेज़ भी पढ़ें। try को यथासंभव सरल रखना बेहतर है। must आरंभीकरण अभिव्यक्तियों में एक सामान्य "पैटर्न" है, लेकिन इसे "ठीक" करने की कोई तत्काल आवश्यकता नहीं है।

@jargv आपके सुझाव के लिए धन्यवाद। यह एक दिलचस्प विचार है (इस विषय पर मेरी टिप्पणी यहां भी देखें)। संक्षेप में:

• try(x) प्रस्तावित के अनुसार संचालित होता है
• try() त्रुटि परिणाम की ओर इशारा करते हुए *error $ लौटाता है

यह वास्तव में परिणाम प्राप्त करने का एक और तरीका होगा w/o इसे नाम देना।

@cespare @jargv का सुझाव मेरे लिए आपके द्वारा प्रस्तावित किए जा रहे सुझावों से कहीं अधिक सरल लगता है। यह परिणाम त्रुटि तक पहुंच की समान समस्या को हल करता है। तुम क्या सोचते हो?

https://github.com/golang/go/issues/32437#issuecomment -499320588 के अनुसार:

func doPanic (त्रुटि त्रुटि) त्रुटि {आतंक (गलती)}

मुझे आशा है कि यह समारोह काफी सामान्य होगा। क्या इसे "बिल्टिन" (या मानक पैकेज में कहीं और जैसे errors ) में पूर्वनिर्धारित किया जा सकता है?

बहुत बुरा है कि आप जेनरिक को लागू करने के लिए पर्याप्त शक्तिशाली होने का अनुमान नहीं लगाते हैं
कोशिश करो, मैं वास्तव में आशा करता कि ऐसा करना संभव होगा।

हां, यह प्रस्ताव पहला कदम हो सकता है, हालांकि मुझे इसमें ज्यादा फायदा नहीं दिख रहा है
यह खुद के रूप में यह अब खड़ा है।

दी, इस मुद्दे पर शायद विस्तृत विकल्पों पर बहुत अधिक ध्यान दिया गया है,
लेकिन इससे पता चलता है कि कई प्रतिभागी इससे पूरी तरह खुश नहीं हैं
यह। ऐसा लगता है कि इस प्रस्ताव के बारे में व्यापक सहमति की कमी है...

ऑप वीआर 7 जून। 2019 01:04 श्राफ पीजे नोटिफिकेशन @github.com :

एस्पर #32437 (टिप्पणी)
https://github.com/golang/go/issues/32437#issuecomment-499320588 :

func doPanic (त्रुटि त्रुटि) त्रुटि {आतंक (गलती)}

मुझे आशा है कि यह समारोह काफी सामान्य होगा। क्या इसे पूर्वनिर्धारित किया जा सकता है
"बिलिन" में?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ69WSN मुद्दा
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

@pjebs , मैंने दर्जनों बार समकक्ष कार्य लिखा है। मैं आमतौर पर इसे "ऑर्डी" या "चेक" कहता हूं। यह बहुत आसान है, इसे मानक पुस्तकालय का हिस्सा बनाने की कोई वास्तविक आवश्यकता नहीं है। इसके अलावा अलग-अलग लोग लॉगिंग या समाप्ति से पहले जो कुछ भी चाहते हैं।

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

यह विशिष्ट त्रुटि प्रबंधन प्रस्ताव एक पूर्व-घोषित फ़ंक्शन try पेश करके बॉयलरप्लेट को कम करने का प्रयास करता है जो कुछ परिस्थितियों में प्रवाह नियंत्रण को बदलता है। जेनरिक कभी भी नियंत्रण के प्रवाह को नहीं बदलेगा। इसलिए मैं वास्तव में संबंध नहीं देखता।

इस पर मेरी प्रारंभिक प्रतिक्रिया एक 👎 थी जैसा कि मैंने कल्पना की थी कि किसी फ़ंक्शन के भीतर कई त्रुटि प्रवण कॉलों को संभालने से defer त्रुटि हैंडल भ्रमित हो जाएगा। पूरे प्रस्ताव को पढ़ने के बाद, मैंने अपनी प्रतिक्रिया को ❤️ और पर फ़्लिप कर दिया है क्योंकि मुझे पता चला है कि यह अभी भी अपेक्षाकृत कम जटिलता के साथ प्राप्त किया जा सकता है।

@carlmjohnson हाँ यह आसान है लेकिन ...

मैंने दर्जनों बार समकक्ष कार्य लिखा है।

पूर्व-घोषित फ़ंक्शन के लाभ हैं:

1. हम इसे एक-पंक्ति कर सकते हैं
2. हमें अपने द्वारा उपयोग किए जाने वाले प्रत्येक पैकेज में एरर => पैनिक फ़ंक्शन को फिर से घोषित करने की आवश्यकता नहीं है, या इसके लिए एक सामान्य स्थान बनाए रखने की आवश्यकता नहीं है। चूंकि गो समुदाय में शायद सभी के लिए यह आम है, इसलिए "मानक पैकेज" इसके लिए _ _ सामान्य स्थान है।

@griesemer मूल प्रयास प्रस्ताव के त्रुटि-हैंडलर संस्करण के साथ, त्रुटि को वापस करने के लिए व्यापक कार्य की आवश्यकता अब आवश्यक नहीं है।

जब मैंने पहली बार इसके बारे में गलती => घबराहट के बारे में पूछा, तो मुझे बताया गया कि प्रस्ताव ने इसे माना लेकिन इसे बहुत खतरनाक माना (अच्छे कारण के लिए)। लेकिन अगर हम ऐसे परिदृश्य में त्रुटि-प्रबंधक के बिना try() का उपयोग करते हैं जहां ओवररचिंग फ़ंक्शन त्रुटि वापस नहीं करता है, तो इसे संकलन-समय त्रुटि में बनाने से प्रस्ताव में चर्चा की गई चिंता कम हो जाती है

@pjebs किसी त्रुटि को वापस करने के लिए व्यापक फ़ंक्शन की आवश्यकता मूल डिज़ाइन _if_ में एक त्रुटि हैंडलर प्रदान करने की आवश्यकता नहीं थी। लेकिन यह try की एक और जटिलता है। इसे सरल रखना बेहतर है। इसके बजाय, एक अलग must फ़ंक्शन होना स्पष्ट होगा, जो हमेशा त्रुटि से घबराता है (लेकिन अन्यथा try जैसा है)। फिर यह स्पष्ट है कि कोड में क्या होता है और किसी को संदर्भ को देखने की आवश्यकता नहीं है।

इस तरह के must होने का मुख्य आकर्षण यह होगा कि इसका उपयोग यूनिट परीक्षणों के साथ किया जा सकता है; विशेष रूप से यदि testing पैकेज को must के कारण होने वाली घबराहट से उबरने के लिए उपयुक्त रूप से समायोजित किया गया था और उन्हें एक अच्छे तरीके से परीक्षण विफलताओं के रूप में रिपोर्ट किया गया था। लेकिन एक और नया भाषा तंत्र क्यों जोड़ें जब हम TestXxx(t *testing.T) error फॉर्म के परीक्षण फ़ंक्शन को स्वीकार करने के लिए परीक्षण पैकेज को समायोजित कर सकते हैं? अगर वे एक त्रुटि लौटाते हैं, जो कि बिल्कुल स्वाभाविक लगती है (शायद हमें इसे शुरू से ही करना चाहिए था), तो try ठीक काम करेगा। स्थानीय परीक्षणों को थोड़ा और काम करने की आवश्यकता होगी, लेकिन यह शायद संभव है।

must के लिए अन्य अपेक्षाकृत सामान्य उपयोग वैश्विक प्रारंभिक अभिव्यक्तियों ( must(regexp.Compile... , आदि) में है। अगर "अच्छा होना" होगा, लेकिन यह जरूरी नहीं कि इसे एक नई भाषा सुविधा के लिए आवश्यक स्तर तक बढ़ाए।

@griesemer यह देखते हुए कि must अस्पष्ट रूप से try से संबंधित है, और यह देखते हुए कि गति try लागू होने की ओर है, क्या आपको नहीं लगता कि must पर विचार करना अच्छा है

संभावना है कि यदि इस दौर में इस पर चर्चा नहीं की जाती है, तो इसे कम से कम 3+ वर्षों (या शायद कभी) के लिए लागू नहीं किया जाएगा/गंभीरता से विचार नहीं किया जाएगा। चर्चा में ओवरलैप खरोंच और रीसाइक्लिंग चर्चाओं से शुरू होने के बजाय भी अच्छा होगा।

बहुत से लोगों ने कहा है कि must तारीफ try बहुत अच्छी तरह से।

@pjebs यह निश्चित रूप से प्रकट नहीं होता है कि अभी " try लागू होने की दिशा में कोई गति" है ... - और हमने इसे केवल दो दिन पहले ही पोस्ट किया है। न ही कुछ तय हुआ है। आइए इसे कुछ समय दें।

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

सभी टिप्पणियों और विस्तृत डिज़ाइन दस्तावेज़ को पढ़ने में घंटों बिताने के बाद मैं इस प्रस्ताव में अपने विचार जोड़ना चाहता था।

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

चिंताओं

आस्थगित का दुर्भाग्यपूर्ण ओवरलोडिंग

खतरनाक के रूप में defer की स्पष्ट और सीधी प्रकृति को अधिभारित करने की प्राथमिकता। अगर मैं defer closeFile(f) लिखता हूं जो मेरे लिए सीधा और स्पष्ट है कि क्या हो रहा है और क्यों; func के अंत में जिसे बुलाया जाएगा। और defer के लिए panic() और recover() का उपयोग करते समय कम स्पष्ट है, मैं शायद ही कभी इसका उपयोग करता हूं और दूसरे के कोड को पढ़ते समय इसे लगभग कभी नहीं देखता हूं।

त्रुटियों को संभालने के लिए defer को ओवरलोड करने के लिए स्पू स्पष्ट और भ्रमित करने वाला नहीं है। कीवर्ड defer क्यों? क्या defer का अर्थ _"शायद बाद में?" के बजाय _"बाद में करें"_ नहीं है?

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

महत्वपूर्ण उपयोग-मामले की पुष्टि करने वाले कोई आंकड़े नहीं

जैसा कि @prologic ने उल्लेख किया है, क्या यह try() प्रस्ताव कोड के एक बड़े प्रतिशत पर आधारित है जो इस उपयोग-मामले का उपयोग करेगा, या इसके बजाय यह उन लोगों को शांत करने के प्रयास पर आधारित है जिन्होंने गो त्रुटि प्रबंधन के बारे में शिकायत की है?

काश मैं जानता था कि हर फाइल की पूरी समीक्षा किए बिना और नोट्स लिए बिना आपको अपने कोड बेस से आंकड़े कैसे देना है; मुझे नहीं पता कि @prologic कैसे खुश था, हालांकि उसने ऐसा किया।

लेकिन अनजाने में मुझे आश्चर्य होगा अगर try() ने मेरे 5% उपयोग-मामलों को संबोधित किया और संदेह होगा कि यह 1% से कम को संबोधित करेगा। क्या आप निश्चित रूप से जानते हैं कि दूसरों के परिणाम काफी भिन्न होते हैं? क्या आपने मानक पुस्तकालय का एक सबसेट लिया है और यह देखने की कोशिश की है कि इसे कैसे लागू किया जाएगा?

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

डेवलपर्स के लिए त्रुटियों को अनदेखा करना आसान बनाता है

यह दूसरों की टिप्पणियों का कुल दोहराव है, लेकिन जो मूल रूप से try() प्रदान करता है, वह कई मायनों में केवल मुहावरेदार कोड के रूप में निम्नलिखित को गले लगाने के समान है, और यह कोड है जो कभी भी किसी भी कोड में अपना रास्ता नहीं खोजेगा। डेवलपर जहाजों का सम्मान करना:

f, _ := os.Open(filename)

मुझे पता है कि मैं अपने कोड में बेहतर हो सकता हूं, लेकिन मुझे यह भी पता है कि हम में से कई अन्य गो डेवलपर्स पर निर्भर हैं जो कुछ जबरदस्त उपयोगी पैकेज प्रकाशित करते हैं, लेकिन मैंने _"अदर पीपल्स कोड (टीएम)"_ में जो देखा है उससे त्रुटि प्रबंधन में सर्वोत्तम प्रथाओं की अक्सर अनदेखी की जाती है।

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

(ज्यादातर) पहले से ही यूजरलैंड में try() लागू कर सकते हैं

जब तक मैं प्रस्ताव को गलत नहीं समझता - जो मैं शायद करता हूं - यहां उपयोगकर्तालैंड में लागू गो प्लेग्राउंड में try() है, यद्यपि केवल एक (1) वापसी मूल्य के साथ और अपेक्षित प्रकार के बजाय एक इंटरफ़ेस लौटा रहा है:

package main

import (
    "errors"
    "fmt"
    "strings"
)
func main() {
    defer func() {
        r := recover()
        if r != nil && strings.HasPrefix(r.(string),"TRY:") {
            fmt.Printf("Ouch! %s",strings.TrimPrefix(r.(string),"TRY: "))
        }
    }()
    n := try(badjuju()).(int)
    fmt.Printf("Just chillin %dx!",n)   
}
func badjuju() (int,error) {
    return 10, errors.New("this is a really bad error")
}
func try(args ...interface{}) interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0]
}

तो उपयोगकर्ता एक try2() , try3() जोड़ सकता है और इस पर निर्भर करता है कि उन्हें कितने वापसी मूल्यों की आवश्यकता है।

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

func try(args ...interface{}) ...interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0:len(args)-2]
}

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

स्पष्टता की कमी

प्रस्ताव के कोड का अध्ययन करते समय मैंने पाया कि व्यवहार स्पष्ट नहीं है और इसके बारे में तर्क करना कुछ कठिन है।

जब मैं try() एक व्यंजक को लपेटता हुआ देखता हूं, तो क्या होगा यदि कोई त्रुटि वापस आती है?

क्या त्रुटि को नजरअंदाज कर दिया जाएगा? या यह पहले या सबसे हाल के defer पर कूद जाएगा, और यदि ऐसा है तो यह स्वचालित रूप से बंद होने के अंदर err नामक एक चर सेट करेगा, या इसे पैरामीटर के रूप में पास करेगा _(I पैरामीटर नहीं दिख रहा है?)_। और यदि स्वचालित त्रुटि नाम नहीं है, तो मैं इसे कैसे नाम दूं? और क्या इसका मतलब यह है कि मैं संघर्ष से बचने के लिए अपने फ़ंक्शन में अपना स्वयं err चर घोषित नहीं कर सकता?

और क्या यह सभी defer s को कॉल करेगा? उल्टे क्रम में या नियमित क्रम में?

या यह बंद होने और func दोनों से वापस आएगा जहां त्रुटि वापस की गई थी? _(कुछ ऐसा जो मैंने कभी नहीं सोचा होता अगर मैं यहां उन शब्दों को नहीं पढ़ता जो इसका मतलब है।)_

प्रस्ताव और अब तक की सभी टिप्पणियों को पढ़ने के बाद भी मुझे अभी भी ईमानदारी से उपरोक्त प्रश्नों के उत्तर नहीं पता हैं। क्या हम उस भाषा में उस तरह की विशेषता जोड़ना चाहते हैं जिसके समर्थक _"कप्तान स्पष्ट" होने के नाते चैंपियन हैं?

नियंत्रण का अभाव

defer का उपयोग करते हुए, ऐसा प्रतीत होता है कि केवल नियंत्रण डेवलपर्स को _(सबसे हाल का?)_ defer पर शाखा देना होगा। लेकिन मेरे अनुभव में किसी भी तरीके से एक मामूली func से परे यह आमतौर पर उससे अधिक जटिल होता है।

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

उदाहरण के लिए, मैं पांच (5) func कॉल कर सकता हूं जो किसी अन्य func के भीतर से error() #$ लौटाती हैं; आइए उन्हें A() , B() , C() , D() , और E() लेबल करें। मुझे अपनी त्रुटि प्रबंधन के लिए C() की आवश्यकता हो सकती है, A() , B() , D() , और E() कुछ त्रुटि प्रबंधन साझा करने के लिए, और विशिष्ट प्रबंधन के लिए B() और E() ।

लेकिन मुझे विश्वास नहीं है कि इस प्रस्ताव के साथ ऐसा करना संभव होगा। कम से कम आसानी से तो नहीं।

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

_ "हम इन उपयोग-मामलों को संबोधित करने के लिए मौजूदा भाषा में मामूली वृद्धि क्यों नहीं कर सकते हैं और नए बिल्टिन फ़ंक्शंस जोड़ने या भ्रमित करने वाले अर्थशास्त्र को स्वीकार करने की आवश्यकता नहीं है?" _

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

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

break . के लिए घोषित समर्थन का अभाव

ऐसा महसूस हो सकता है कि यह बाएं क्षेत्र से आता है क्योंकि अधिकांश लोग त्रुटि प्रबंधन के लिए शुरुआती रिटर्न का उपयोग करते हैं, लेकिन मैंने पाया है कि break त्रुटि प्रबंधन के लिए return से पहले अधिकांश या सभी func को लपेटने के लिए उपयोग करना बेहतर होता है।

मैंने कुछ समय के लिए इस दृष्टिकोण का उपयोग किया है और अकेले रिफैक्टरिंग को आसान बनाने में इसके लाभ इसे शुरुआती return के लिए बेहतर बनाते हैं, लेकिन इसके कई अन्य लाभ हैं जिनमें एकल निकास बिंदु और एक func के एक भाग को जल्दी समाप्त करने की क्षमता शामिल है लेकिन फिर भी क्लीनअप चलाने में सक्षम _(शायद यही कारण है कि मैं शायद ही कभी defer का उपयोग करता हूं, जिसे प्रोग्राम प्रवाह के संदर्भ में तर्क करना मुझे कठिन लगता है।)_

जल्दी वापसी के बजाय break का उपयोग करने के लिए _ से बाहर निकलने के लिए ब्रेक के लिए एक ब्लॉक बनाने के लिए for range "1" {...} लूप का उपयोग करें (मैं वास्तव में only नामक एक पैकेज बनाता हूं जिसमें केवल स्थिरांक होता है Once के मूल्य के साथ "1" कहा जाता है):_

func (me *Config) WriteFile() (err error) {
    for range only.Once {
        var j []byte
        j, err = json.MarshalIndent(me, "", "    ")
        if err != nil {
            err = fmt.Errorf("unable to marshal config; %s", 
                err.Error(),
            )
            break
        }
        err = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to make directory'%s'; %s", 
                me.GetDir(), 
                err.Error(),
            )
            break
        }
        err = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to write to config file '%s'; %s", 
                me.GetFilepath(), 
                err.Error(),
            )
            break
        }
    }
    return err
}

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

लेकिन मैं पीछे हटा। इसे यहां लाने का मेरा कारण यह है कि मुझे त्रुटि प्रबंधन को लागू करने के लिए गो के लिए होगा जो return s की शुरुआत में मानता है और त्रुटि प्रबंधन के लिए break का उपयोग करके अनदेखा करता है

मेरी राय err == nil समस्याग्रस्त है

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

तो गो 2 के लिए मैं वास्तव में देखना चाहता हूं कि गो एक नया बिल्टिन प्रकार status और तीन बिल्टिन फ़ंक्शंस iserror() , iswarning() , issuccess() जोड़ने पर विचार करें। status error #$ को लागू कर सकता है - बहुत पिछड़ी संगतता के लिए अनुमति देता है और nil मान issuccess() पर पारित हो जाता है जो issuccess() true - लेकिन status में त्रुटि स्तर के लिए एक अतिरिक्त आंतरिक स्थिति होगी ताकि त्रुटि स्तर के लिए परीक्षण हमेशा अंतर्निहित कार्यों में से एक के साथ किया जाएगा और आदर्श रूप से कभी भी nil चेक के साथ नहीं किया जाएगा। इसके बजाय निम्न दृष्टिकोण की तरह कुछ अनुमति देगा:

func (me *Config) WriteFile() (sts status) {
    for range only.Once {
        var j []byte
        j, sts = json.MarshalIndent(me, "", "    ")
        if iserror(sts) {
            sts.AddMessage("unable to marshal config")
            break
        }
        sts = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to make directory'%s'", me.GetDir())
            break
        }
        sts = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to write to config file '%s'", 
                me.GetFilepath(), 
            )
            break
        }
        sts = fmt.Status("config file written")
    }
    return sts
}

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

यदि आपको लगता है कि इस दृष्टिकोण के लिए मुहावरेदार गो कोड विकसित करने का कोई मौका है, तो कृपया इस try() प्रस्ताव पर विचार करते समय त्रुटि प्रबंधन को लागू करते समय इसे ध्यान में रखें।

_"सभी के लिए नहीं"_ औचित्य

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

क्या यह नया जटिल भाषा में परिवर्तन है जिसके लिए सभी को नई अवधारणाओं को सीखने की आवश्यकता होगी, वास्तव में उपयोग-मामलों की एक आकर्षक संख्या को संबोधित करते हैं?

और क्या यह नहीं है कि कोर टीम के समान औचित्य सदस्यों ने समुदाय से कई फीचर अनुरोधों को अस्वीकार कर दिया है? गो टीम के एक सदस्य द्वारा लगभग 2 साल पहले सबमिट किए गए एक फीचर अनुरोध के लिए एक विशिष्ट प्रतिक्रिया में की गई टिप्पणी का एक सीधा उद्धरण निम्नलिखित है _(मैं उस व्यक्ति या विशिष्ट फीचर अनुरोध का नाम नहीं ले रहा हूं क्योंकि यह चर्चा सक्षम नहीं होनी चाहिए लोगों के बजाय भाषा के बारे में):_

_"एक नई भाषा सुविधा के लिए सम्मोहक उपयोग के मामलों की आवश्यकता होती है। सभी भाषा सुविधाएँ उपयोगी हैं, या कोई भी उन्हें प्रस्तावित नहीं करेगा; सवाल यह है: क्या वे भाषा को जटिल बनाने और सभी को नई अवधारणाओं को सीखने की आवश्यकता को सही ठहराने के लिए पर्याप्त उपयोगी हैं? सम्मोहक उपयोग क्या हैं यहां मामले हैं? लोग इनका उपयोग कैसे करेंगे? उदाहरण के लिए, क्या लोग उम्मीद करेंगे कि वे सक्षम हों ... और यदि ऐसा है तो वे ऐसा कैसे करेंगे? क्या यह प्रस्ताव आपको अनुमति देने से अधिक करता है...?"_
— एक कोर गो टीम सदस्य

सच कहूं तो जब मैंने उन प्रतिक्रियाओं को देखा है तो मैंने दो भावनाओं में से एक महसूस किया है:

1. आक्रोश अगर यह एक ऐसी विशेषता है जिससे मैं सहमत हूं, या
2. उत्साह अगर यह एक ऐसी विशेषता है जिससे मैं सहमत नहीं हूं।

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

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

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

यदि वास्तविक दुनिया के उपयोग-मामलों के एक सम्मोहक सेट की आवश्यकता सभी समुदाय-जनित सुविधा प्रस्तावों के लिए बार है, तो क्या यह _ सभी _ सुविधा प्रस्तावों के लिए समान बार नहीं होना चाहिए?

कोशिश का घोंसला ()

यह भी कुछ लोगों द्वारा कवर किया गया था, लेकिन मैं try() और टर्नरी ऑपरेटरों के लिए निरंतर अनुरोध के बीच तुलना करना चाहता हूं। लगभग 18 महीने पहले गो टीम के एक अन्य सदस्य की टिप्पणियों का हवाला देते हुए:

_"जब "बड़े पैमाने पर प्रोग्रामिंग" (लंबी अवधि में बड़ी टीमों के साथ बड़े कोड आधार), कोड को लिखे जाने की तुलना में अधिक बार पढ़ा जाता है, इसलिए हम पठनीयता के लिए अनुकूलित करते हैं, न कि लेखन योग्यता के लिए।"_

टर्नरी ऑपरेटरों को न जोड़ने के लिए _प्राथमिक_ बताए गए कारणों में से एक यह है कि नेस्टेड होने पर उन्हें पढ़ना मुश्किल होता है और/या गलत तरीके से पढ़ना आसान होता है। फिर भी नेस्टेड try() स्टेटमेंट जैसे try(try(try(to()).parse().this)).easily()) के बारे में भी यही सच हो सकता है।

टर्नरी ऑपरेटरों के खिलाफ बहस के अतिरिक्त कारण यह रहे हैं कि वे _"एक्सप्रेशन"_ हैं, इस तर्क के साथ कि नेस्टेड एक्सप्रेशन जटिलता जोड़ सकते हैं। लेकिन क्या try() एक नेस्टेबल एक्सप्रेशन भी नहीं बनाता है?

अब यहाँ किसी ने कहा _"मुझे लगता है कि [नेस्टेड try() s] जैसे उदाहरण अवास्तविक हैं"_ और उस कथन को चुनौती नहीं दी गई थी।

लेकिन अगर लोग यह स्वीकार करते हैं कि डेवलपर्स try() घोंसला नहीं बनाएंगे, तो टर्नरी ऑपरेटरों को वही सम्मान क्यों नहीं दिया जाता है जब लोग कहते हैं _ "मुझे लगता है कि गहराई से नेस्टेड टर्नरी ऑपरेटर अवास्तविक हैं?"_

इस बिंदु के लिए नीचे की रेखा, मुझे लगता है कि अगर टर्नरी ऑपरेटरों के खिलाफ तर्क वास्तव में मान्य हैं, तो उन्हें भी इस try() प्रस्ताव के खिलाफ वैध तर्क माना जाना चाहिए।

सारांश

इस लेखन के समय 58% डाउन वोट 42% अप वोटों के लिए। मुझे लगता है कि यह केवल यह इंगित करने के लिए पर्याप्त होना चाहिए कि यह एक प्रस्ताव के लिए पर्याप्त विभाजनकारी है कि इस मुद्दे पर ड्राइंग बोर्ड पर लौटने का समय आ गया है।

fwiw

पीएस इसे और अधिक जीभ-गाल रखने के लिए, मुझे लगता है कि हमें योड की व्याख्यात्मक ज्ञान का पालन करना चाहिए:

_"कोई try() नहीं है। केवल do() ।"_

@ianlancetaylor

@beoran शायद आप जेनरिक और त्रुटि प्रबंधन के बीच संबंध पर विस्तार कर सकते हैं।

@beoran के लिए नहीं बोल रहा हूं, लेकिन कुछ मिनट पहले की मेरी टिप्पणी में आप देखेंगे कि अगर हमारे पास जेनरिक _(प्लस वैरिएडिक रिटर्न पैरामीटर)_ होते तो हम अपना खुद try() बना सकते थे।

हालाँकि - और मैं यहाँ जेनरिक के बारे में ऊपर कही गई बातों को दोहराऊँगा जहाँ यह देखना आसान होगा:

_" मुझे लगता है कि जेनरिक के लिए उपयोग-मामलों को जावा वगैरह से जेनरिक के भ्रमित करने वाले शब्दार्थ और सिंटैक्स सलाद को जोड़ने के बजाय जेनेरिक के उपयोग-मामलों को संबोधित करने के लिए बिलिन्स जोड़कर कम किया जाना चाहिए।)"_

@ianlancetaylor

आपके प्रश्न का उत्तर तैयार करने का प्रयास करते समय, मैंने गो में try फ़ंक्शन को लागू करने का प्रयास किया, और मेरी खुशी के लिए, वास्तव में कुछ समान अनुकरण करना पहले से ही संभव है:

func try(v interface{}, err error) interface{} {
   if err != nil { 
     panic(err)
   }
   return v
}

यहां देखें कि इसका उपयोग कैसे किया जा सकता है: https://play.golang.org/p/Kq9Q0hZHlXL

इस दृष्टिकोण के नुकसान हैं:

1. एक आस्थगित बचाव की आवश्यकता है, लेकिन इस प्रस्ताव में try के साथ, यदि हम उचित त्रुटि प्रबंधन करना चाहते हैं तो एक आस्थगित हैंडलर की भी आवश्यकता है। इसलिए मुझे लगता है कि यह कोई गंभीर कमी नहीं है। यह और भी बेहतर हो सकता है अगर गो के पास किसी प्रकार का super(arg1, ..., argn) बिल्टिन कॉलर के कॉलर का कारण बनता है, कॉल स्टैक ऊपर एक स्तर, दिए गए तर्कों के साथ लौटने के लिए arg1,...argn, एक प्रकार का सुपर रिटर्न अगर आप करें तो।
2. यह try मैंने लागू किया है जो केवल एक फ़ंक्शन के साथ काम कर सकता है जो एक परिणाम और एक त्रुटि देता है।
3. आपको दिए गए emtpy इंटरफ़ेस परिणामों पर जोर देना होगा।

पर्याप्त रूप से शक्तिशाली जेनेरिक समस्या 2 और 3 को हल कर सकते हैं, केवल 1 को छोड़कर, जिसे super() जोड़कर हल किया जा सकता है। उन दो सुविधाओं के साथ, हम कुछ ऐसा प्राप्त कर सकते हैं:

func (T ... interface{})try(T, err error) super {
   if err != nil { 
      super(err)
   }
  super(T...)
}

और तब आस्थगित बचाव की अब और आवश्यकता नहीं होगी। यह लाभ तब भी मिलेगा जब गो में कोई जेनरिक नहीं जोड़ा जाएगा।

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

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

मुझे प्रस्ताव पसंद है लेकिन तथ्य यह है कि आपको स्पष्ट रूप से निर्दिष्ट करना था कि defer try(...) और go try(...) की अनुमति नहीं है, मुझे लगता है कि कुछ बिल्कुल सही नहीं था .... ऑर्थोगोनैलिटी एक अच्छी डिजाइन गाइड है। आगे पढ़ने और देखने पर जैसी चीज़ें
x = try(foo(...)) y = try(bar(...))
मुझे आश्चर्य है कि try हो सकता है एक संदर्भ होने की जरूरत है! विचार करना:
try ( x = foo(...) y = bar(...) )
यहां foo() और bar() दो मान लौटाते हैं, जिनमें से दूसरा है error । केवल try ब्लॉक के भीतर कॉल के लिए शब्दार्थ का प्रयास करें, जहां लौटाए गए त्रुटि मान को अनदेखा किया गया है (कोई रिसीवर नहीं) जैसा कि अनदेखा किया गया है (रिसीवर _ है)। आप foo और bar कॉल के बीच कुछ त्रुटियों को भी संभाल सकते हैं।

सारांश:
a) try के लिए go और defer को अस्वीकार करने की समस्या वाक्य रचना के आधार पर गायब हो जाती है।
बी) कई कार्यों की त्रुटि प्रबंधन को दूर किया जा सकता है।
ग) इसकी जादुई प्रकृति को फ़ंक्शन कॉल की तुलना में विशेष सिंटैक्स के रूप में बेहतर ढंग से व्यक्त किया जाता है।

यदि कोशिश एक संदर्भ है तो हमने अभी कोशिश/पकड़ ब्लॉक बनाए हैं जिन्हें हम विशेष रूप से टालने की कोशिश कर रहे हैं (और अच्छे कारण के लिए)

कोई पकड़ नहीं है। ठीक उसी कोड को जनरेट किया जाएगा जब वर्तमान प्रस्ताव है
x = try(foo(...)) y = try(bar(...))
यह सिर्फ अलग वाक्य रचना है, शब्दार्थ नहीं।
````

मुझे लगता है कि मैंने इसके बारे में कुछ धारणाएँ बनाई थीं जो मुझे नहीं करनी चाहिए थीं, हालाँकि इसमें अभी भी कुछ कमियाँ हैं।

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

दूसरी बात यह है कि आमतौर पर keyword ( ... ) सिंटैक्स का अर्थ है कि आप प्रत्येक पंक्ति पर कीवर्ड को उपसर्ग करते हैं। तो आयात, var, const, आदि के लिए: प्रत्येक पंक्ति कीवर्ड से शुरू होती है। उस नियम का अपवाद बनाना एक अच्छा निर्णय नहीं लगता

किसी फ़ंक्शन का उपयोग करने के बजाय, एक विशेष पहचानकर्ता का उपयोग करके अधिक मूर्खतापूर्ण होगा?

हमारे पास पहले से ही रिक्त पहचानकर्ता _ है जो मूल्यों की उपेक्षा करता है।
हमारे पास # जैसा कुछ हो सकता है जिसका उपयोग केवल उन कार्यों में किया जा सकता है जिनके पास प्रकार की त्रुटि का अंतिम लौटाया गया मान है।

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

जब कोई त्रुटि # को असाइन की जाती है तो फ़ंक्शन प्राप्त त्रुटि के साथ तुरंत वापस आ जाता है। अन्य चरों के लिए उनके मान होंगे:

• यदि उनका नाम शून्य मान नहीं है
• नामित चर को सौंपा गया मान अन्यथा

@deanveloper , try ब्लॉक सेमेन्टिक्स केवल उन कार्यों के लिए मायने रखता है जो एक त्रुटि मान लौटाते हैं और जहां त्रुटि मान असाइन नहीं किया जाता है। अतः वर्तमान प्रस्ताव का अंतिम उदाहरण इस प्रकार भी लिखा जा सकता है
try(x = foo(...)) try(y = bar(...))
दोनों कथनों को एक ही ब्लॉक में रखना, import , const और var कथनों को दोहराए जाने के समान है।

अब यदि आपके पास है, उदा
try( x = foo(...)) go zee(...) defer fum() y = bar(...) )
यह लिखने के बराबर है
try(x = foo(...)) go zee(...) defer fum() try(y = bar(...))
एक कोशिश ब्लॉक में उन सभी को फैक्टरिंग करने से यह कम व्यस्त हो जाता है।

विचार करना
try(x = foo())
यदि foo() त्रुटि मान वापस नहीं करता है, तो यह बराबर है
x = foo()

विचार करना
try(f, _ := os.open(filename))
चूंकि लौटाए गए त्रुटि मान को अनदेखा किया जाता है, यह जस्ट . के बराबर है
f, _ := os.open(filename)

विचार करना
try(f, err := os.open(filename))
चूंकि लौटाए गए त्रुटि मान को अनदेखा नहीं किया जाता है, यह बराबर है
f, err := os.open(filename) if err != nil { return ..., err }
जैसा कि वर्तमान में प्रस्ताव में निर्दिष्ट है।

और यह नेस्टेड कोशिशों को भी अच्छी तरह से अस्वीकार कर देता है!

यहाँ उस वैकल्पिक प्रस्ताव का लिंक दिया गया है जिसका मैंने ऊपर उल्लेख किया है:

• https://github.com/golang/go/issues/32473

यह try() . के समान उपयोग के मामलों को संबोधित करने के लिए दो (2) छोटी लेकिन सामान्य प्रयोजन वाली भाषा सुविधाओं को जोड़ने का आह्वान करता है

1. असाइनमेंट स्टेटमेंट में func /क्लोजर को कॉल करने की क्षमता।
2. break , continue या return एक से अधिक स्तरों की क्षमता।

इन दो विशेषताओं के साथ उनका कोई _"जादू"_ नहीं होगा और मेरा मानना ​​है कि उनका उपयोग गो कोड का उत्पादन करेगा जो समझने में आसान है और मुहावरेदार गो कोड के साथ अधिक इनलाइन है जिससे हम सभी परिचित हैं।

मैंने प्रस्ताव पढ़ा है और वास्तव में पसंद है कि कोशिश कहाँ जा रही है।

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

मानचित्रों पर विचार करें। यह मान्य है:

v := m[key]

जैसा यह है:

v, ok := m[key]

क्या होगा अगर हम त्रुटियों को ठीक उसी तरह से संभालते हैं जिस तरह से सुझाव देते हैं, लेकिन बिल्टिन को हटा दें। तो अगर हमने इसके साथ शुरुआत की:

v, err := fn()

लिखने के बजाय:

v := try(fn())

हम इसके बजाय लिख सकते हैं:

v := fn()

जब त्रुटि मान कैप्चर नहीं किया जाता है, तो इसे ठीक उसी तरह से हैंडल किया जाता है जैसे कि कोशिश करता है। इसकी आदत पड़ने में थोड़ा समय लगेगा, लेकिन यह v, ok := m[key] और v, ok := x.(string) के समान ही लगता है। मूल रूप से, किसी भी अनहेल्ड त्रुटि के कारण फ़ंक्शन वापस आ जाता है और त्रुटि मान सेट हो जाता है।

डिज़ाइन डॉक्स के निष्कर्षों और कार्यान्वयन आवश्यकताओं पर वापस जाने के लिए:

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

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

तो प्रस्ताव से CopyFile उदाहरण के साथ defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) का उपयोग करते हुए, हम प्राप्त करते हैं:

func CopyFile(src, dst string) (err error) {
        defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)

        r := os.Open(src)
        defer r.Close()

        w := os.Create(dst)
        defer func() {
                err := w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        io.Copy(w, r)
        w.Close()
        return nil
}

@savaki मुझे यह पसंद है और इस बारे में सोच रहा था कि डिफ़ॉल्ट रूप से त्रुटियों को हमेशा संभालकर त्रुटि प्रबंधन को फ़्लिप करने के लिए क्या करना होगा और प्रोग्रामर को यह निर्दिष्ट करने दें कि ऐसा कब नहीं करना है (गलती को एक चर में कैप्चर करके) लेकिन किसी की कुल कमी पहचानकर्ता कोड का पालन करना कठिन बना देगा क्योंकि कोई भी सभी रिटर्न पॉइंट नहीं देख पाएगा। उन कार्यों को नाम देने के लिए एक सम्मेलन हो सकता है जो एक त्रुटि को अलग तरीके से वापस कर सकते हैं (जैसे सार्वजनिक पहचानकर्ताओं को कैपिटल करना)। हो सकता है कि यदि किसी फ़ंक्शन ने कोई त्रुटि लौटाई है, तो उसे हमेशा समाप्त होना चाहिए, मान लें कि ? । तब गो हमेशा परोक्ष रूप से त्रुटि को संभाल सकता है और कोशिश की तरह ही इसे कॉलिंग फ़ंक्शन पर स्वचालित रूप से वापस कर सकता है। यह कुछ प्रस्तावों के समान है जो कोशिश के बजाय ? पहचानकर्ता का उपयोग करने का सुझाव देता है लेकिन एक महत्वपूर्ण अंतर यह है कि यहां ? फ़ंक्शन के नाम का हिस्सा होगा, न कि अतिरिक्त पहचानकर्ता। वास्तव में एक फ़ंक्शन जो error को अंतिम वापसी मूल्य के रूप में लौटाता है, वह भी संकलित नहीं होगा यदि ? प्रत्यय नहीं है। बेशक ? मनमाना है और इसे किसी और चीज से बदला जा सकता है जिससे इरादा अधिक स्पष्ट हो। operation?() रैपिंग के बराबर होगा try(someFunc()) लेकिन ? फ़ंक्शन नाम का हिस्सा होगा और इसका एकमात्र उद्देश्य यह इंगित करना होगा कि फ़ंक्शन कैपिटलाइज़िंग की तरह एक त्रुटि लौटा सकता है एक चर का पहला अक्षर।

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

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

क्या हम पुराने कार्यों के लिए सज्जाकारों के साथ c++ अपवादों जैसा कुछ कर सकते हैं?

func some_old_test() (int, error){
    return 0, errors.New("err1")
}
func some_new_test() (int){
        if true {
             return 1
        }
    throw errors.New("err2")
}
func throw_res(int, e error) int {
    if e != nil {
        throw e
    }
    return int
}
func main() {
    fmt.Println("Hello, playground")
    try{
        i := throw_res(some_old_test())
        fmt.Println("i=", i + some_new_test())
    } catch(err io.Error) {
        return err
    } catch(err error) {
        fmt.Println("unknown err", err)
    }
}

@owais मैं सोच रहा था कि शब्दार्थ बिल्कुल वैसा ही होगा जैसा कि try तो बहुत कम से कम आपको गलत प्रकार की घोषणा करने की आवश्यकता होगी। तो अगर हमने इसके साथ शुरुआत की:

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

अगर मैं कोशिश प्रस्ताव को समझता हूं, तो बस यह कर रहा हूं:

func foo() error {
  _  := fn() 
  return nil
} 

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

यह तब काम करेगा:

func foo() (err error) {
  _  := fn() 
  return nil
} 

क्यों न केवल एक त्रुटि के मामले को संभालें जो एक चर को असाइन नहीं किया गया है।

• नामित रिटर्न की आवश्यकता को हटा दें, कंपाइलर यह सब अपने आप कर सकता है।
• संदर्भ जोड़ने की अनुमति देता है।
• सामान्य उपयोग के मामले को संभालता है।
• पीछे संगत
• अजीब तरह से इंटरैक्ट नहीं करता है w / defer, लूप या स्विच।

अगर गलती के लिए निहित वापसी! = शून्य मामला, कंपाइलर रिटर्न के लिए स्थानीय चर नाम उत्पन्न कर सकता है यदि आवश्यक हो तो प्रोग्रामर द्वारा एक्सेस नहीं किया जा सकता है।
व्यक्तिगत रूप से मैं इस विशेष मामले को कोड पठनीयता स्टैंडपॉइंट से नापसंद करता हूं

f := os.Open("foo.txt")

एक स्पष्ट वापसी पसंद करते हैं, इस प्रकार कोड लिखित मंत्र से अधिक पढ़ा जाता है

f := os.Open("foo.txt") else return

दिलचस्प बात यह है कि हम दोनों रूपों को स्वीकार कर सकते हैं, और gofmt स्वचालित रूप से अन्य रिटर्न जोड़ सकते हैं।

संदर्भ जोड़ना, चर का स्थानीय नामकरण भी। वापसी स्पष्ट हो जाती है क्योंकि हम संदर्भ जोड़ना चाहते हैं।

f := os.Open("foo.txt") else err {
  return errors.Wrap(err, "some context")
}

एकाधिक वापसी मूल्यों के साथ संदर्भ जोड़ना

f := os.Open("foo.txt") else err {
  return i, j, errors.Wrap(err, "some context")
}

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

bits := ioutil.ReadAll(os.Open("foo")) else err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

कंपाइलर फ़ंक्शन में त्रुटि वापसी मान गुम होने के कारण संकलन से इनकार करता है

func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

खुशी से संकलित करता है क्योंकि त्रुटि को स्पष्ट रूप से अनदेखा किया जाता है।

func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
} 

संकलक खुश है। यह त्रुटि को अनदेखा करता है क्योंकि यह वर्तमान में करता है क्योंकि कोई असाइनमेंट या अन्य प्रत्यय नहीं होता है।

func foo() error {
  return errors.New("whoops")
}

func bar() {
  foo()
}

एक लूप के भीतर आप जारी रखें का उपयोग कर सकते हैं।

for _, s := range []string{"1","2","3","4","5","6"} {
  i := strconv.Atoi(s) else continue
}

संपादित करें: ; को else . से बदल दिया गया

@savaki मुझे लगता है कि मैं आपकी मूल टिप्पणी को समझ गया हूं और मुझे डिफ़ॉल्ट रूप से त्रुटियों को संभालने का विचार पसंद है, लेकिन मुझे नहीं लगता कि यह कुछ अतिरिक्त वाक्यविन्यास परिवर्तनों को जोड़ने के बिना व्यवहार्य है और एक बार जब हम ऐसा करते हैं, तो यह वर्तमान प्रस्ताव के समान ही हो जाता है।

आप जो प्रस्ताव देते हैं उसका सबसे बड़ा पहलू यह है कि यह उन सभी बिंदुओं को उजागर नहीं करता है जहां से कोई फ़ंक्शन वर्तमान if err != nil {return err} या इस प्रस्ताव में पेश किए गए प्रयास फ़ंक्शन के विपरीत वापस आ सकता है। भले ही यह हुड के नीचे ठीक उसी तरह काम करेगा, नेत्रहीन रूप से कोड बहुत अलग दिखाई देगा। कोड पढ़ते समय, यह जानने का कोई तरीका नहीं होगा कि कौन सी फ़ंक्शन कॉल त्रुटि लौटा सकती है। यह अपवाद आईएमओ से भी बदतर अनुभव होगा।

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

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

सुनिश्चित नहीं है कि ऐसा कुछ पहले सुझाया गया है, इसे यहां या प्रस्ताव में नहीं मिल रहा है। क्या आपने एक और बिल्टिन फ़ंक्शन माना है जो वर्तमान फ़ंक्शन के त्रुटि वापसी मान पर पॉइंटर देता है?
उदाहरण:

func example() error {
        var err *error = funcerror() // always return a non-nil pointer
        fmt.Print(*err) // always nil if the return parameters are not named and not in a defer

        defer func() {
                err := funcerror()
                fmt.Print(*err) // "x"
        }

        return errors.New("x")
}

func exampleNamed() (err error) {
        funcErr := funcerror()
        fmt.Print(*funcErr) // "nil"

        err = errors.New("x")
        fmt.Print(*funcErr) // "x", named return parameter is reflected even before return is called

        *funcErr = errors.New("y")
        fmt.Print(err) // "y", unfortunate side effect?

        defer func() {
                funcErr := funcerror()
                fmt.Print(*funcErr) // "z"
                fmt.Print(err) // "z"
        }

        return errors.New("z")
}

कोशिश के साथ प्रयोग:

func CopyFile(src, dst string) (error) {
        defer func() {
                err := funcerror()
                if *err != nil {
                        *err = fmt.Errorf("copy %s %s: %v", src, dst, err)
                }
        }()
        // one liner alternative
        // defer fmt.HandleErrorf(funcerror(), "copy %s %s", src, dst)

        r := try(os.Open(src))
        defer r.Close()

        w := try(os.Create(dst))
        defer func() {
                w.Close()
                err := funcerror()
                if *err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try(io.Copy(w, r))
        try(w.Close())
        return nil
}

वैकल्पिक रूप से funcerror (नाम एक कार्य प्रगति पर है :D ) यदि आस्थगित नहीं कहा जाता है तो शून्य वापस आ सकता है।

एक अन्य विकल्प यह है कि funcerror इसे केवल पढ़ने के लिए बनाने के लिए "त्रुटिकर्ता" इंटरफ़ेस देता है:

type interface Errorer() {
        Error() error
}

@savaki मैं वास्तव में try() को छोड़ने के आपके प्रस्ताव को पसंद करता हूं और इसे मानचित्र या एक प्रकार के दावे का परीक्षण करने की अनुमति देता हूं। यह बहुत अधिक लगता है _"गो-लाइक।"_

हालांकि, अभी भी एक स्पष्ट समस्या है जो मुझे दिखाई दे रही है, और वह है आपका प्रस्ताव यह मानता है कि इस दृष्टिकोण का उपयोग करने वाली सभी त्रुटियां return को ट्रिगर करेंगी और फ़ंक्शन को छोड़ देंगी। यह जो विचार नहीं करता है वह वर्तमान for break वर्तमान for continue लिए continue जारी कर रहा है।

शुरुआती return s एक स्लेजहैमर हैं जब कई बार एक स्केलपेल बेहतर विकल्प होता है।

इसलिए मैं दावा करता हूं कि break और continue को वैध त्रुटि प्रबंधन रणनीतियों की अनुमति दी जानी चाहिए और वर्तमान में आपका प्रस्ताव केवल return $ मानता है जबकि try() यह मानता है कि या एक त्रुटि बुला रहा है हैंडलर जो स्वयं केवल return , break या continue नहीं कर सकता है।

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

@mikeschinkel मेरा एक्सटेंशन देखें, उनके और मेरे समान विचार थे, मैंने इसे एक वैकल्पिक ब्लॉक स्टेटमेंट के साथ बढ़ाया था

@ जेम्स-लॉरेंस

@mikesckinkel मेरा एक्सटेंशन देखें, उनके और मेरे पास समान विचार थे, मैंने इसे एक वैकल्पिक ब्लॉक स्टेटमेंट के साथ बढ़ाया था

अपना उदाहरण लेते हुए:

f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

जिसकी तुलना आज हम करते हैं:

f,err := os.Open("foo.txt"); 
if err != nil {
  return errors.Wrap(err, "some context")
}

निश्चित रूप से मेरे लिए बेहतर है। सिवाय इसके कुछ मुद्दे हैं:

1. err _"जादुई"_ घोषित प्रतीत होता है। जादू कम से कम होना चाहिए, नहीं? तो चलिए इसे घोषित करते हैं:

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

1. लेकिन यह अभी भी काम नहीं करता है क्योंकि गो nil false रूप में नहीं करता है और न ही सूचक मानों को true के रूप में व्याख्या करता है, इसलिए इसे होना चाहिए:

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

और वह क्या काम करता है, यह एक पंक्ति में बस इतना ही काम और बहुत सारे वाक्य-विन्यास की तरह लगने लगता है, इसलिए और मैं स्पष्टता के लिए पुराने तरीके से काम करना जारी रख सकता हूं।

लेकिन क्या होगा अगर गो ने दो (2) बिल्टिन जोड़े; iserror() और error() ? तब हम ऐसा कर सकते थे, जो मुझे उतना बुरा नहीं लगता:

f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

या बेहतर _(कुछ इस तरह):_

f := os.Open("foo.txt"); iserror() {
  return error().Extend("some context")
}

आप और अन्य क्या सोचते हैं?

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

@mikeschinkel उस नाम के बारे में खेद है जो मैं अपने फोन पर था और जिथब स्वतः सुझाव नहीं दे रहा था।

त्रुटि "जादुई" घोषित प्रतीत होती है। जादू कम से कम होना चाहिए, नहीं? तो चलिए इसे घोषित करते हैं:

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

मैं आम तौर पर त्रुटियों के पैकेज में आने वाले परिवर्धन के साथ गो की त्रुटि प्रबंधन से बहुत खुश हूं। मुझे इस प्रस्ताव में कुछ भी सुपर सहायक के रूप में नहीं दिख रहा है। अगर हम इसे करने के लिए तैयार हैं तो मैं सिर्फ गोलंग के लिए सबसे प्राकृतिक फिट पेश करने का प्रयास कर रहा हूं।

_"रिटर्न को स्वचालित रूप से सम्मिलित करने का संपूर्ण विचार जादुई है।"_

आपको वहां मुझसे कोई तर्क नहीं मिलेगा।

_"इस पूरे प्रस्ताव में शायद ही सबसे जादुई बात चल रही हो।"_

मुझे लगता है कि मैं यह तर्क देने की कोशिश कर रहा था कि _ "सभी जादू समस्याग्रस्त है।" _

_ "इसके अलावा मैं तर्क दूंगा कि गलती घोषित की गई थी, अंत में एक स्कोप्ड ब्लॉक के संदर्भ में ..." _

तो अगर मैं इसे err2 कहना चाहता हूं तो यह भी काम करेगा?

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

इसलिए मुझे लगता है कि आप सेमी-कोलन के बाद err / err2 के विशेष केस हैंडलिंग का भी प्रस्ताव कर रहे हैं, यानी कि इसे या तो nil माना जाएगा या नहीं nil bool जैसे मानचित्र की जाँच करते समय?

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

मैं आम तौर पर त्रुटियों के पैकेज में आने वाले परिवर्धन के साथ गो की त्रुटि प्रबंधन से बहुत खुश हूं।

break और continue _(लेकिन return ) के साथ संयुक्त होने पर, मैं भी त्रुटि प्रबंधन से खुश हूं।

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

@beoran @mikeschinkel पहले मैंने सुझाव दिया था कि हम जेनरिक का उपयोग करके try के इस संस्करण को लागू नहीं कर सकते, क्योंकि यह नियंत्रण प्रवाह को बदल देता है। अगर मैं सही ढंग से पढ़ रहा हूं, तो आप दोनों सुझाव दे रहे हैं कि हम try को panic पर कॉल करके लागू करने के लिए जेनेरिक का उपयोग कर सकते हैं। लेकिन try का यह संस्करण बहुत स्पष्ट रूप से panic नहीं है। इसलिए हम try के इस संस्करण को लागू करने के लिए जेनरिक का उपयोग नहीं कर सकते।

हां, हम एक फ़ंक्शन लिखने के लिए जेनेरिक (जेनेरिक का एक संस्करण https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md पर डिज़ाइन मसौदे में दिए गए संस्करण की तुलना में काफी अधिक शक्तिशाली) का उपयोग कर सकते हैं। जो गलती से घबरा जाता है। लेकिन त्रुटि पर घबराना उस तरह की त्रुटि प्रबंधन नहीं है जो आज गो प्रोग्रामर लिखते हैं, और यह मेरे लिए एक अच्छा विचार नहीं लगता है।

@mikeschinkel विशेष हैंडलिंग यह होगी कि त्रुटि होने पर ही ब्लॉक निष्पादित होता है।
```
एफ: = ओएस। ओपन ('फू'); गलती {वापसी गलती}//गलती हमेशा गैर-शून्य होगी।

@ianlancetaylor

_ "हां, हम जेनरिक का उपयोग कर सकते हैं ... लेकिन त्रुटि पर घबराना उस तरह की त्रुटि प्रबंधन नहीं है जो आज गो प्रोग्रामर लिखते हैं, और यह मेरे लिए एक अच्छा विचार नहीं लगता है।"_

मैं वास्तव में इस पर आपके साथ दृढ़ता से सहमत हूं इस प्रकार ऐसा प्रतीत होता है कि आपने मेरी टिप्पणी के इरादे को गलत समझा होगा। मैं यह बिल्कुल भी सुझाव नहीं दे रहा था कि गो टीम panic() का उपयोग करने वाले त्रुटि प्रबंधन को लागू करेगी - बिल्कुल नहीं।

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

मैं क्या नहीं कर रहा था - और शायद यह स्पष्ट नहीं था - इस बात की वकालत कर रहा था कि लोग वास्तव में panic() का उपयोग $#$4 try() panic() को लागू करने के लिए करते हैं, बस वे कर सकते हैं यदि वे वास्तव में चाहते थे, और उनके पास की विशेषताएं थीं जेनरिक।

क्या यह स्पष्ट करता है?

मेरे लिए panic पर कॉल करना, हालांकि यह किया जाता है, try के इस प्रस्ताव से काफी अलग है। इसलिए जब तक मुझे लगता है कि मैं समझता हूं कि आप क्या कह रहे हैं, मैं इस बात से सहमत नहीं हूं कि वे समकक्ष हैं। यहां तक ​​​​कि अगर हमारे पास try के एक संस्करण को लागू करने के लिए पर्याप्त शक्तिशाली जेनरिक थे, तो मुझे लगता है कि इस प्रस्ताव में प्रस्तुत try के संस्करण के लिए अभी भी एक उचित इच्छा होगी।

@ianlancetaylor ने स्वीकार किया। दोबारा, मैं एक कारण ढूंढ रहा था कि इसे जोड़ने का तरीका खोजने के बजाय try() को जोड़ने की आवश्यकता नहीं होगी। जैसा कि मैंने ऊपर कहा है, मेरे पास यहां प्रस्तावित try() की तुलना में त्रुटि प्रबंधन के लिए कुछ भी नया नहीं होगा।

विशुद्ध रूप से दृश्य पहलुओं के आधार पर, मुझे व्यक्तिगत रूप से इससे पहले check प्रस्ताव अधिक पसंद आया; check में इस try() जैसी ही शक्ति थी लेकिन bar(check foo()) मेरे लिए bar(try(foo())) की तुलना में अधिक पठनीय है (मुझे माता-पिता की गणना करने के लिए बस एक सेकंड की आवश्यकता है!)

इससे भी महत्वपूर्ण बात यह है कि handle / check के बारे में मेरी मुख्य शिकायत यह थी कि यह अलग-अलग चेकों को अलग-अलग तरीकों से लपेटने की अनुमति नहीं देता था - और अब इस try() प्रस्ताव में एक ही दोष है, टालमटोल और नामित रिटर्न की मुश्किल शायद ही कभी इस्तेमाल की जाने वाली नौसिखिया-भ्रमित करने वाली विशेषताओं का आह्वान करते हुए। और handle के साथ कम से कम हमारे पास हैंडल ब्लॉकों को परिभाषित करने के लिए स्कोप का उपयोग करने का विकल्प था, defer के साथ भी यह संभव नहीं है।

जहां तक ​​मेरा संबंध है, यह प्रस्ताव हर एक मामले में पहले के handle / check प्रस्ताव से हार जाता है।

त्रुटि प्रबंधन के लिए defers का उपयोग करने के साथ यहां एक और चिंता है।

try एक फ़ंक्शन से नियंत्रित/इच्छित निकास है। कार्यों से अनियंत्रित/अनपेक्षित निकास सहित, defers हमेशा चलते हैं। यह बेमेल भ्रम पैदा कर सकता है। यहाँ एक काल्पनिक परिदृश्य है:

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

याद रखें कि नेट/http आतंक से उबरता है, और कल्पना करें कि आतंक के आसपास उत्पादन समस्या को डीबग करना है। आप अपने इंस्ट्रुमेंटेशन को देखेंगे और recordMetric कॉल से डीबी कॉल विफलताओं में एक स्पाइक देखेंगे। यह असली समस्या को छुपा सकता है, जो कि अगली पंक्ति में घबराहट है।

मुझे यकीन नहीं है कि व्यवहार में यह कितनी गंभीर चिंता है, लेकिन यह (दुख की बात है) शायद यह सोचने का एक और कारण है कि त्रुटि प्रबंधन के लिए defer एक आदर्श तंत्र नहीं है।

यहां एक संशोधन दिया गया है जो उठाई गई कुछ चिंताओं में मदद कर सकता है: try को return के बजाय goto return तरह मानें। मेरी बात सुनो। :)

try इसके बजाय वाक्यात्मक चीनी होगा:

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

लाभ:

• त्रुटियों को सजाने के लिए defer की आवश्यकता नहीं है। (नामित रिटर्न अभी भी आवश्यक हैं, हालांकि।)
• error: लेबल का अस्तित्व एक दृश्य सुराग है कि फ़ंक्शन में कहीं try है।

यह हैंडलर जोड़ने के लिए एक तंत्र भी प्रदान करता है जो हैंडलर-ए-फ़ंक्शन समस्याओं को दूर करता है: हैंडलर के रूप में लेबल का उपयोग करें। try(fn(), wrap) $ के बजाय goto wrap goto error । कंपाइलर पुष्टि कर सकता है कि फ़ंक्शन में wrap: मौजूद है। ध्यान दें कि हैंडलर होने से डिबगिंग में भी मदद मिलती है: आप डिबगिंग पथ प्रदान करने के लिए हैंडलर को जोड़/बदल सकते हैं।

नमूना कोड:

func CopyFile(src, dst string) (err error) {
    r := try(os.Open(src))
    defer r.Close()

    w := try(os.Create(dst))
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    try(io.Copy(w, r), copyfail)
    try(w.Close())
    return nil

error:
    return fmt.Errorf("copy %s %s: %v", src, dst, err)

copyfail:
    recordMetric("copy failure") // count incidents of this failure
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

अन्य टिप्पणियां:

• हम चाहते हैं कि try के लक्ष्य के रूप में उपयोग किए जाने वाले किसी भी लेबल को समाप्ति कथन से पहले किया जाए। व्यवहार में, यह उन्हें समारोह के अंत में मजबूर करेगा और कुछ स्पेगेटी कोड को रोक सकता है। दूसरी ओर, यह कुछ उचित, उपयोगी उपयोगों को रोक सकता है।
• लूप बनाने के लिए try का उपयोग किया जा सकता है। मुझे लगता है कि यह "अगर दर्द होता है, तो ऐसा मत करो" के बैनर तले आता है, लेकिन मुझे यकीन नहीं है।
• इसके लिए https://github.com/golang/go/issues/26058 को ठीक करना होगा।

श्रेय: मेरा मानना ​​​​है कि इस विचार का एक प्रकार पहली बार @griesemer द्वारा पिछले साल गोफरकॉन में व्यक्तिगत रूप से सुझाया गया था।

@josarian panic के साथ बातचीत के बारे में सोचना यहां महत्वपूर्ण है, और मुझे खुशी है कि आपने इसे लाया, लेकिन आपका उदाहरण मुझे अजीब लगता है। निम्नलिखित कोड में यह मेरे लिए कोई मतलब नहीं है कि defer हमेशा "db call failed" मीट्रिक रिकॉर्ड करता है। यदि someHTTPHandlerGuts सफल होता है और nil लौटाता है तो यह एक गलत मीट्रिक होगा। defer सभी निकास मामलों में चलता है, न कि केवल त्रुटि या घबराहट के मामलों में, इसलिए कोई घबराहट न होने पर भी कोड गलत लगता है।

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

@josarian हाँ, यह कमोबेश ठीक वैसा ही संस्करण है जिस पर हमने पिछले साल चर्चा की थी (सिवाय इसके कि हमने try के बजाय try check का उपयोग किया)। मुझे लगता है कि यह महत्वपूर्ण होगा कि एक बार जब हम error लेबल पर हों, तो हम बाकी फ़ंक्शन बॉडी में "वापस" नहीं जा सकते। यह सुनिश्चित करेगा कि goto कुछ हद तक "संरचित" है (कोई स्पेगेटी कोड संभव नहीं है)। एक चिंता जो सामने आई थी वह यह थी कि त्रुटि हैंडलर ( error: ) लेबल हमेशा फ़ंक्शन के अंत में समाप्त होगा (अन्यथा किसी को इसके चारों ओर कूदना होगा)। व्यक्तिगत रूप से, मुझे त्रुटि प्रबंधन कोड रास्ते से बाहर (अंत में) पसंद है, लेकिन अन्य लोगों ने महसूस किया कि यह शुरुआत में ही दिखाई देना चाहिए।

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

मेरे पीओवी से, मुझे ऐसा नहीं लगता कि इस कोशिश सिंटैक्स को हर उपयोग के मामले को संभालना है जैसे मुझे नहीं लगता कि मुझे इसका उपयोग करने की आवश्यकता है

वी, ठीक: = एम [कुंजी]

मानचित्र से पढ़ने से प्रपत्र

आप handle / check प्रस्ताव को सरलीकृत रूप में पुनर्जीवित करके फ़ंक्शन के अंत में हैंडलर को मजबूर करने वाले गोटो लेबल से बच सकते हैं। क्या होगा यदि हम handle err { ... } सिंटैक्स का उपयोग करते हैं, लेकिन केवल हैंडलर्स को चेन नहीं होने देते हैं, इसके बजाय केवल अंतिम का उपयोग किया जाता है। यह उस प्रस्ताव को बहुत सरल करता है, और गोटो विचार के समान ही है, सिवाय इसके कि यह हैंडलिंग को उपयोग के बिंदु के करीब रखता है।

func CopyFile(src, dst string) (err error) {
    handle err {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    r := check os.Open(src)
    defer r.Close()

    w := check os.Create(dst)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “check” fails
        }
    }()

    {
        // handlers are scoped, after this scope the original handle is used again.
        // as an alternative, we could have repeated the first handle after the io.Copy,
        // or come up with a syntax to name the handlers, though that's often not useful.
        handle err {
            recordMetric("copy failure") // count incidents of this failure
            return fmt.Errorf("copy %s %s: %v", src, dst, err)
        }
        check io.Copy(w, r)
    }
    check w.Close()
    return nil
}

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

@josharian @griesemer यदि आप नामित हैंडलर पेश करते हैं (जो अनुरोध किए गए चेक/हैंडल करने के लिए कई प्रतिक्रियाएं हैं, आवर्ती थीम देखें), try(f(), err) के लिए बेहतर वाक्यविन्यास विकल्प हैं:

try.err f()
try?err f()
try#err f()

?err    f() // because 'try' is redundant
?return f() // no handler
?panic  f() // no handler

(?err f()).method()

f?err() // lead with function name, instead of error handling
f?err().method()

file, ?err := os.Open(...) // many check/handle responses also requested this style

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

मेरे लिए एक अंतर्निहित फ़ंक्शन को "कोशिश" करने और श्रृंखलाओं को सक्षम करने में 2 समस्याएं हैं:

• यह बाकी नियंत्रण प्रवाह के साथ असंगत है (उदाहरण के लिए,/if/रिटर्न/आदि कीवर्ड के लिए)।
• यह कोड को कम पठनीय बनाता है।

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

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

FWIW, panic नियंत्रण प्रवाह को प्रभावित करता है और इसमें माता-पिता होते हैं, लेकिन go और defer भी प्रवाह को प्रभावित करते हैं और नहीं। मुझे लगता है कि try defer के समान है क्योंकि यह एक असामान्य प्रवाह संचालन है और इसे करना कठिन बना देता है try (try os.Open(file)).Read(buf) अच्छा है क्योंकि हम एक-लाइनर्स को हतोत्साहित करना चाहते हैं वैसे भी, लेकिन जो भी हो। कुछ भी चलेगा।

अंतिम त्रुटि वापसी चर के लिए एक निहित नाम के लिए सुझाव हर कोई नफरत करेगा: $err । यह try() आईएमओ से बेहतर है। :-)

@griesemer

_ "व्यक्तिगत रूप से, मुझे त्रुटि प्रबंधन कोड पसंद है (अंत में)"_

उस पर +1!

मुझे लगता है कि त्रुटि प्रबंधन को लागू किया गया _before_ त्रुटि उत्पन्न होती है, त्रुटि से निपटने के बारे में तर्क करना बहुत कठिन है _after_ त्रुटि उत्पन्न होती है। मानसिक रूप से वापस कूदना और तर्क प्रवाह का पालन करने के लिए मजबूर होना ऐसा लगता है कि मैं 1980 में वापस आ गया हूं और GOTO के साथ बेसिक लिख रहा हूं।

मुझे फिर से उदाहरण के रूप में CopyFile() का उपयोग करके त्रुटियों को संभालने का एक और संभावित तरीका प्रस्तावित करने दें:

func CopyFile(src, dst string) (err error) {

    r := os.Open(src)
    defer r.Close()

    w := os.Create(dst)
    defer w.Close()

    io.Copy(w, r)
    w.Close()

    for err := error {
        switch err.Source() {
        case w.Close:
            os.Remove(dst) // only if a “try” fails
            fallthrough
        case os.Open, os.Create, io.Copy:
            err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        default:
            err = fmt.Errorf("an unexpected error occurred")
        }
    }

    return err
}

आवश्यक भाषा परिवर्तन होंगे:

1. for error{} निर्माण की अनुमति दें, $#$3 for range{} #$ के समान, लेकिन केवल एक त्रुटि पर दर्ज किया गया और केवल एक बार निष्पादित किया गया।

2. <object>.Error() string को लागू करने वाले रिटर्न मानों को कैप्चर करने की अनुमति दें, लेकिन केवल तभी जब for error{} निर्माण उसी func के भीतर मौजूद हो।

3. जब कोई func अपने अंतिम रिटर्न मान में _"त्रुटि"_ लौटाता है, तो प्रोग्राम नियंत्रण प्रवाह for error{} निर्माण की पहली पंक्ति में कूदने के लिए कारण बनता है।

4. एक _"त्रुटि"_ लौटाते समय गो उस फंक का एक संदर्भ जोड़ देगा जो त्रुटि लौटाता है जिसे <error>.Source() द्वारा पुनर्प्राप्त किया जा सकता है

एक _"त्रुटि"_ क्या है?

वर्तमान में एक _"त्रुटि"_ को किसी भी वस्तु के रूप में परिभाषित किया गया है जो Error() string लागू करता है और निश्चित रूप से nil नहीं है।

हालांकि, एक RESTful API के सफलता परिणामों के लिए आवश्यक रिटर्निंग मानों की अनुमति देने के लिए अक्सर त्रुटि _even on Success_ को विस्तारित करने की आवश्यकता होती है। इसलिए मैं पूछूंगा कि गो टीम कृपया स्वचालित रूप से err!=nil का अर्थ _"त्रुटि"_ न मानें, बल्कि इसके बजाय जांचें कि क्या कोई त्रुटि ऑब्जेक्ट IsError() लागू करता है और यदि IsError() true देता है nil मान एक _"त्रुटि" है।

_(मैं मानक पुस्तकालय में कोड के बारे में आवश्यक रूप से बात नहीं कर रहा हूं, लेकिन मुख्य रूप से यदि आप _"त्रुटि"_ पर शाखा में अपना नियंत्रण प्रवाह चुनते हैं। यदि आप केवल err!=nil को देखते हैं तो हम जो कुछ भी करते हैं उसमें हम बहुत सीमित होंगे हमारे कार्यों में वापसी मूल्यों के संदर्भ में कर सकते हैं।)_

बीटीडब्लू, सभी को _"त्रुटि"_ के लिए परीक्षण करने की इजाजत देता है, वैसे ही एक नया बिल्टिन iserror() फ़ंक्शन जोड़कर शायद सबसे आसानी से किया जा सकता है:

type ErrorIser interface {
    IsError() bool
}
func iserror(err error) bool {
    if err == nil { 
        return false
    }
    if _,ok := err.(ErrorIser); !ok {
        return true
    }
    return err.IsError()
}

_"त्रुटियों"_ के गैर-कैप्चरिंग की अनुमति देने का एक पक्ष लाभ

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

मेरे लिए, _ "क्या मुझे एक त्रुटि वापस करनी चाहिए या सादगी को कॉल करने के लिए त्रुटि प्रबंधन करना चाहिए?" _ गो कोड लिखते समय मेरी सबसे बड़ी उलझनों में से एक है। उपरोक्त _"त्रुटियों"_ के गैर-कैप्चरिंग की अनुमति देने से वह विवाद समाप्त हो जाएगा।

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

https://github.com/rhysd/trygo

मैंने विस्तारित भाषा को ट्राईगो कहा और ट्राईगो टू गो अनुवादक को लागू किया।

अनुवादक के साथ, कोड

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd := try(os.Getwd())

    try(os.Mkdir(filepath.Join(cwd, subdir)))

    p := filepath.Join(cwd, subdir, filename)
    f := try(os.Create(p))
    defer f.Close()

    try(f.Write(content))

    fmt.Println("Created:", p)
    return nil
}

में अनुवाद किया जा सकता है

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd, _err0 := os.Getwd()
    if _err0 != nil {
        return _err0
    }

    if _err1 := os.Mkdir(filepath.Join(cwd, subdir)); _err1 != nil {
        return _err1
    }

    p := filepath.Join(cwd, subdir, filename)
    f, _err2 := os.Create(p)
    if _err2 != nil {
        return _err2
    }
    defer f.Close()

    if _, _err3 := f.Write(content); _err3 != nil {
        return _err3
    }

    fmt.Println("Created:", p)
    return nil
}

भाषा के प्रतिबंध के लिए, मैं सामान्य try() कॉल को लागू नहीं कर सका। यह प्रतिबंधित है

• परिभाषा कथन का RHS
• असाइनमेंट स्टेटमेंट का RHS
• कॉल स्टेटमेंट

लेकिन मैं इसे अपने छोटे प्रोजेक्ट के साथ आजमा सकता था। मेरा अनुभव था

• यह मूल रूप से ठीक काम करता है और कई लाइनों को बचाता है
• नामित रिटर्न वैल्यू वास्तव में err के लिए अनुपयोगी है क्योंकि इसके फ़ंक्शन का रिटर्न वैल्यू असाइनमेंट और try() विशेष फ़ंक्शन दोनों द्वारा निर्धारित किया जाता है। बहुत ज्यादा उलझन
• जैसा कि ऊपर चर्चा की गई है, इस try() फ़ंक्शन में 'रैपिंग एरर' सुविधा का अभाव था।

_"ये दोनों मुझे अच्छे परिणाम लगते हैं।"_

हमें यहां असहमत होने के लिए सहमत होना होगा।

_ "यह कोशिश सिंटैक्स (हर उपयोग के मामले को संभालने की जरूरत नहीं है)"_

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

यदि हम यहां उस औचित्य की अनुमति देते हैं, तो हम उन पिछले प्रस्तावों पर फिर से विचार क्यों नहीं कर सकते जिन्हें ठुकरा दिया गया था क्योंकि वे व्यापक रूप से लागू नहीं थे?

और क्या अब हम गो में उन बदलावों के लिए बहस करने के लिए तैयार हैं जो केवल चुनिंदा किनारे के मामलों के लिए उपयोगी हैं?

मेरे अनुमान में, यह मिसाल कायम करने से लंबे समय तक अच्छे नतीजे नहीं मिलेंगे...

_"@मिकेशेंकेल"_

PS मैंने आपका संदेश गलत वर्तनी के कारण पहले नहीं देखा। _(इससे मुझे ठेस नहीं पहुँचती, जब मेरे उपयोगकर्ता नाम की वर्तनी गलत होती है तो मुझे सूचित नहीं किया जाता...)_

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

• https://github.com/google/go-github
• https://github.com/cockroachdb/cockroach
• https://github.com/golang/net
• https://github.com/exercism/xgo
• https://github.com/GoogleCloudPlatform/kubernetes
• https://github.com/syncthing/syncthing
• https://github.com/mitchellh/packer
• https://github.com/drone/drone
• https://github.com/coreos/etcd
• https://github.com/docker/docker
• https://github.com/sjwhitworth/golearn
• https://github.com/bitly/nsq
• https://github.com/smartystreets/goconvey
• https://github.com/golang/tools
• https://github.com/coreos/fleet
• https://github.com/limetext/लाइम
• https://github.com/flynn/flynn
• https://github.com/dropbox/godropbox
• https://github.com/hashicorp/consul
• https://github.com/hashicorp/terraform

इन रिपॉजिटरी में रहने वाले गो की 11,108,770 महत्वपूर्ण लाइनों में, पहचानकर्ता के रूप में उपयोग किए जाने वाले try के केवल 63 उदाहरण थे। बेशक, मुझे एहसास है कि ये कोडबेस (जबकि बड़े, व्यापक रूप से उपयोग किए जाते हैं, और अपने आप में महत्वपूर्ण हैं) वहां गो कोड के केवल एक अंश का प्रतिनिधित्व करते हैं, और इसके अतिरिक्त, हमारे पास निजी कोडबेस का सीधे विश्लेषण करने का कोई तरीका नहीं है, लेकिन यह निश्चित रूप से है एक दिलचस्प परिणाम।

इसके अलावा, क्योंकि try , किसी भी कीवर्ड की तरह, लोअरकेस है, आप इसे पैकेज के सार्वजनिक एपीआई में कभी नहीं पाएंगे। कीवर्ड जोड़ने से केवल पैकेज आंतरिक प्रभावित होंगे.

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

मैं निम्नलिखित निर्माणों का प्रस्ताव रखूंगा।

1) कोई हैंडलर नहीं

// The existing proposal, but as a keyword rather than builtin.  When an error is 
// "caught", the function returns all zero values plus the error.  Nothing 
// particularly new here.
func doSomething() (int, error) {
    try SomeFunc()
    a, b := try AnotherFunc()

    // ...

    return 123, nil
}

2) हैंडलर

ध्यान दें कि त्रुटि हैंडलर सरल कोड ब्लॉक हैं, जिनका उद्देश्य फ़ंक्शन के बजाय इनलाइन होना है। इस पर और नीचे।

func doSomething() (int, error) {
    // Inline error handler
    a, b := try SomeFunc() else err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    // Named error handlers
    handler logAndContinue err {
        log.Errorf("non-critical error: %v", err)
    }
    handler annotateAndReturn err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    c, d := try SomeFunc() else logAndContinue
    e, f := try OtherFunc() else annotateAndReturn

    // ...

    return 123, nil
}

प्रस्तावित प्रतिबंध:

• आप फ़ंक्शन कॉल केवल try कर सकते हैं। नहीं try err ।
• यदि आप एक हैंडलर निर्दिष्ट नहीं करते हैं, तो आप उस फ़ंक्शन के भीतर से केवल try कर सकते हैं जो एक त्रुटि को उसके सबसे सही रिटर्न मान के रूप में देता है। इसके संदर्भ के आधार पर try के व्यवहार में कोई बदलाव नहीं आया है। यह कभी नहीं घबराता है (जैसा कि सूत्र में बहुत पहले चर्चा की गई है)।
• किसी भी प्रकार की "हैंडलर चेन" नहीं है। हैंडलर सिर्फ इनलाइन करने योग्य कोड ब्लॉक हैं।

लाभ:

• try / else सिंटैक्स को मामूली रूप से मौजूदा "यौगिक अगर" में बदल दिया जा सकता है:
  go a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "error in doSomething:") }
  हो जाता है
  go if a, b, err := SomeFunc(); err != nil { return 0, errors.Wrap(err, "error in doSomething:") }
  मेरी नज़र में, यौगिक ifs हमेशा एक बहुत ही सरल कारण के लिए मददगार की तुलना में अधिक भ्रमित करने वाला लगता है: सशर्त आमतौर पर _after_ एक ऑपरेशन होता है, और इसके परिणामों को संसाधित करने के साथ कुछ करना होता है। यदि ऑपरेशन सशर्त बयान के अंदर लपेटा गया है, तो यह कम स्पष्ट है कि यह हो रहा है। आंख विचलित है। इसके अलावा, परिभाषित चर का दायरा तुरंत स्पष्ट नहीं होता है जब वे एक पंक्ति में सबसे बाईं ओर होते हैं।
• त्रुटि संचालकों को जानबूझकर फ़ंक्शन के रूप में परिभाषित नहीं किया जाता है (न ही फ़ंक्शन-जैसे शब्दार्थ जैसा कुछ भी)। यह हमारे लिए कई काम करता है:
  
  
  
  • कंपाइलर केवल एक नामित हैंडलर को इनलाइन कर सकता है जहाँ भी इसे संदर्भित किया जाता है। यह फ़ंक्शन कॉल की तुलना में एक साधारण मैक्रो/कोडजेन टेम्पलेट की तरह अधिक है। रनटाइम को यह जानने की भी आवश्यकता नहीं है कि हैंडलर मौजूद हैं।
  
  
  • हम इस बारे में सीमित नहीं हैं कि हम एक हैंडलर के अंदर क्या कर सकते हैं। हम check / handle की आलोचना के इर्द-गिर्द घूमते हैं कि "यह त्रुटि प्रबंधन ढांचा केवल खैरात के लिए अच्छा है"। हम "हैंडलर चेन" की आलोचना भी करते हैं। इनमें से किसी एक हैंडलर के अंदर कोई भी मनमाना कोड रखा जा सकता है, और कोई अन्य नियंत्रण प्रवाह निहित नहीं है।
  
  
  • हमें हैंडलर के अंदर return को हाईजैक करने की आवश्यकता नहीं है, जिसका अर्थ है super return । किसी कीवर्ड को हाईजैक करना बेहद भ्रमित करने वाला है। return का अर्थ है return , और super return की कोई वास्तविक आवश्यकता नहीं है।
  
  
  • defer को त्रुटि प्रबंधन तंत्र के रूप में चांदनी की आवश्यकता नहीं है। हम इसे मुख्य रूप से संसाधनों आदि को साफ करने के तरीके के रूप में सोचना जारी रख सकते हैं।
  
  
• त्रुटियों में संदर्भ जोड़ने के संबंध में:
  
  
  
  • हैंडलर के साथ संदर्भ जोड़ना बेहद सरल है और मौजूदा if err != nil ब्लॉक के समान दिखता है
  
  
  • भले ही "हैंडलर के बिना प्रयास करें" निर्माण सीधे संदर्भ जोड़ने को प्रोत्साहित नहीं करता है, फिर भी हैंडलर फॉर्म में रिफैक्टर करना बहुत आसान है। इसका इच्छित उपयोग मुख्य रूप से विकास के दौरान होगा, और अनियंत्रित त्रुटियों को उजागर करने के लिए go vet चेक लिखना बेहद सरल होगा।
  
  

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

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

आपके प्रस्ताव के बारे में: यह बिना नाम वाले संचालकों के भी ठीक रहेगा, है ना? (यह शक्ति के नुकसान के बिना प्रस्ताव को सरल करेगा। कोई केवल इनलाइन हैंडलर से स्थानीय फ़ंक्शन को कॉल कर सकता है।)

आपके प्रस्ताव के बारे में: यह बिना नाम वाले संचालकों के भी ठीक रहेगा, है ना? (यह शक्ति के नुकसान के बिना प्रस्ताव को सरल करेगा। कोई केवल इनलाइन हैंडलर से स्थानीय फ़ंक्शन को कॉल कर सकता है।)

@griesemer वास्तव में - मैं उन लोगों को शामिल करने के बारे में बहुत गुनगुना महसूस कर रहा था। निश्चित रूप से अधिक गो-ईश बिना।

दूसरी ओर, ऐसा लगता है कि लोग एक-लाइनर त्रुटि प्रबंधन करने की क्षमता चाहते हैं, जिसमें एक-लाइनर शामिल हैं जो return । एक सामान्य मामला लॉग होगा, फिर return । यदि हम else क्लॉज में किसी स्थानीय फ़ंक्शन के लिए खोल देते हैं, तो हम शायद इसे खो देते हैं:

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

(मैं अभी भी इसे कंपाउंड इफ्स के लिए पसंद करता हूं, हालांकि)

हालांकि, आप अभी भी एक-लाइनर रिटर्न प्राप्त कर सकते हैं जो थ्रेड में पहले चर्चा की गई एक साधारण gofmt ट्वीक को लागू करके त्रुटि संदर्भ जोड़ते हैं:

a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

क्या उपरोक्त प्रस्ताव में नया कीवर्ड आवश्यक है? क्यों नहीं:

SomeFunc() else return
a, b := SomeOtherFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

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

संचालकों का सुझाव देने वाले किसी भी व्यक्ति को पहले चेक/हैंडल फीडबैक विकी को पढ़ना चाहिए। संभावना अच्छी है कि आप जो कुछ भी सपना देखते हैं वह पहले से ही वर्णित है :-)
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

@smonkewitz नहीं, उस संस्करण में एक नया कीवर्ड आवश्यक नहीं है क्योंकि यह असाइनमेंट स्टेटमेंट के लिए बाध्य है, जिसका अब तक विभिन्न सिंटैक्स चीनी में कई बार उल्लेख किया गया है।

https://github.com/golang/go/issues/32437#issuecomment -499808741
https://github.com/golang/go/issues/32437#issuecomment -499852124
https://github.com/golang/go/issues/32437#issuecomment -500095505

@ianlancetaylor में त्रुटि प्रबंधन का यह विशेष स्वाद अभी तक गो टीम द्वारा माना गया है? इसे लागू करना उतना आसान नहीं है जितना कि प्रस्तावित प्रयास बिलिन लेकिन अधिक मुहावरेदार लगता है। ~अनावश्यक बयान, क्षमा करें।~

मैं कुछ दोहराना चाहूंगा @deanveloper और कुछ अन्य लोगों ने कहा है, लेकिन मेरे अपने जोर के साथ। https://github.com/golang/go/issues/32437#issuecomment -498939499 में @deanveloper ने कहा:

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

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

कुछ लोगों ने तर्क दिया है कि panic ने पहले से ही एक अंतर्निहित फ़ंक्शन के लिए मिसाल कायम की है जो नियंत्रण प्रवाह को बदलता है, लेकिन मुझे लगता है कि panic दो कारणों से मौलिक रूप से अलग है:

1. आतंक सशर्त नहीं है; यह हमेशा कॉलिंग फ़ंक्शन को बंद कर देता है।
2. आतंक किसी भी मूल्य को वापस नहीं करता है और इस प्रकार केवल एक स्टैंडअलोन स्टेटमेंट के रूप में प्रकट हो सकता है, जिससे इसकी दृश्यता बढ़ जाती है।

दूसरी ओर प्रयास करें:

1. सशर्त है; यह कॉलिंग फ़ंक्शन से वापस आ सकता है या नहीं भी।
2. मान देता है और एक मिश्रित अभिव्यक्ति में प्रकट हो सकता है, संभवतः कई बार, एक पंक्ति पर, संभावित रूप से मेरी संपादक विंडो के दाहिने मार्जिन से पहले।

इन कारणों से मुझे लगता है कि try "बिट ऑफ" से अधिक महसूस करता है, मुझे लगता है कि यह मूल रूप से कोड पठनीयता को नुकसान पहुंचाता है।

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

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

````
अगर यह! = "टूट गया" {
नॉट फिक्स (यह)
}

@ChrisHines आपकी बात पर (जो इस धागे में कहीं और गूँजती है), आइए एक और प्रतिबंध जोड़ें:

• कोई भी try स्टेटमेंट (यहां तक ​​कि बिना हैंडलर के भी) अपनी लाइन पर होना चाहिए।

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

तो, इस प्रकार की बकवास में से कोई भी नहीं:

try EmitEvent(try (try DecodeMsg(m)).SaveToDB())

बल्कि यह:

dm := try DecodeMsg(m)
um := try dm.SaveToDB()
try EmitEvent(um)

जो अभी भी इससे अधिक स्पष्ट लगता है:

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

इस डिज़ाइन के बारे में एक बात जो मुझे पसंद है वह यह है कि त्रुटियों को चुपचाप अनदेखा करना असंभव है, बिना यह बताए कि कोई हो सकता है । जबकि अभी, आप कभी-कभी x, _ := SomeFunc() देखते हैं (अनदेखा रिटर्न वैल्यू क्या है? एक त्रुटि? कुछ और?), अब आपको स्पष्ट रूप से एनोटेट करना होगा:

x := try SomeFunc() else err {}

प्रस्ताव के समर्थन में मेरी पिछली पोस्ट के बाद से, मैंने @jagv (पैरामीटर रहित try रिटर्न *error ) और @josharian (लेबल त्रुटि हैंडलर) द्वारा पोस्ट किए गए दो विचार देखे हैं, जिन पर मुझे विश्वास है थोड़ा संशोधित रूप प्रस्ताव को काफी बढ़ा देगा।

थीसिस विचारों को एक साथ रखकर एक और एक के साथ जो मैंने स्वयं लिया है, हमारे पास try के चार संस्करण होंगे:

1. कोशिश करो()
2. कोशिश करो (परम)
3. कोशिश करें (पैरा, लेबल)
4. कोशिश करो (परम, आतंक)

1 केवल त्रुटि रिटर्न पैरामीटर (ईआरपी) या शून्य पर एक पॉइंटर लौटाएगा यदि कोई नहीं था (केवल # 4)। यह एक नामित ईआरपी के लिए एक और बिल्ट-इन जोड़ने की आवश्यकता के बिना एक विकल्प प्रदान करेगा।

2 ठीक उसी तरह काम करेगा जैसा कि वर्तमान में परिकल्पित है। एक गैर-शून्य त्रुटि तुरंत लौटा दी जाएगी लेकिन defer कथन द्वारा सजाया जा सकता है।

3 @josarian द्वारा सुझाए गए अनुसार काम करेगा यानी एक गैर-शून्य त्रुटि पर कोड लेबल पर जाएगा। हालांकि, कोई डिफ़ॉल्ट त्रुटि हैंडलर लेबल नहीं होगा क्योंकि वह मामला अब # 2 में खराब हो जाएगा।

मुझे ऐसा लगता है कि यह आमतौर पर defer की तुलना में त्रुटियों को सजाने (या उन्हें स्थानीय रूप से संभालने और फिर शून्य लौटने) का एक बेहतर तरीका होगा क्योंकि यह आसान और तेज़ है। कोई भी व्यक्ति जिसे यह पसंद नहीं आया वह अब भी #2 का उपयोग कर सकता है।

एरर हैंडलिंग लेबल/कोड को फंक्शन के अंत के पास रखना और फंक्शन बॉडी के बाकी हिस्सों में वापस नहीं जाना सबसे अच्छा अभ्यास होगा। हालांकि, मुझे नहीं लगता कि संकलक को या तो लागू करना चाहिए क्योंकि ऐसे अजीब अवसर हो सकते हैं जहां वे उपयोगी हों और किसी भी मामले में प्रवर्तन मुश्किल हो सकता है।

तो सामान्य लेबल और goto व्यवहार विषय पर लागू होगा (जैसा कि @josharian ने कहा) #26058 पर पहले तय किया जा रहा है लेकिन मुझे लगता है कि इसे वैसे भी तय किया जाना चाहिए।

लेबल का नाम panic नहीं हो सकता क्योंकि यह #4 के साथ विरोध करेगा।

4 वापस लौटने या शाखा लगाने के बजाय तुरंत panic होगा। नतीजतन, यदि यह किसी विशेष फ़ंक्शन में उपयोग किए जाने वाले try का एकमात्र संस्करण था, तो किसी ईआरपी की आवश्यकता नहीं होगी।

मैंने इसे इसलिए जोड़ा है ताकि परीक्षण पैकेज काम कर सके जैसा कि अब बिना किसी अंतर्निहित या अन्य परिवर्तनों की आवश्यकता के करता है। हालाँकि, यह अन्य _fatal_ परिदृश्यों में भी उपयोगी हो सकता है।

यह एक त्रुटि हैंडलर के लिए ब्रांचिंग के विकल्प के रूप में try का एक अलग संस्करण होना चाहिए और फिर इससे घबराने के लिए अभी भी एक ईआरपी की आवश्यकता होगी।

प्रारंभिक प्रस्ताव के लिए सबसे मजबूत प्रकार की प्रतिक्रियाओं में से एक सामान्य प्रवाह की आसान दृश्यता खोने के बारे में चिंता थी जहां एक समारोह वापस आता है।

उदाहरण के लिए, @deanveloper ने https://github.com/golang/go/issues/32437#issuecomment -498932961 में उस चिंता को बहुत अच्छी तरह से व्यक्त किया, जो मुझे लगता है कि यहां सबसे ज्यादा अपवोट की गई टिप्पणी है।

@dominikh ने https://github.com/golang/go/issues/32437#issuecomment -499067357 में लिखा:

gofmt'ed कोड में, एक रिटर्न हमेशा /^\t*return / से मेल खाता है - यह बिना किसी सहायता के आंखों से देखने के लिए एक बहुत ही छोटा पैटर्न है। दूसरी ओर, कोड में कहीं भी हो सकता है, फ़ंक्शन कॉल में मनमाने ढंग से गहरा घोंसला। प्रशिक्षण की कोई भी राशि हमें टूल सहायता के बिना किसी फ़ंक्शन में सभी नियंत्रण प्रवाह को तुरंत पहचानने में सक्षम नहीं बनाती है।

इसके साथ मदद करने के लिए, @brynbellomy ने कल सुझाव दिया:

कोई भी कोशिश कथन (यहां तक ​​​​कि बिना हैंडलर के भी) अपनी लाइन पर होना चाहिए।

इसे और आगे ले जाते हुए, try को एक असाइनमेंट के लिए भी लाइन की शुरुआत होने की आवश्यकता हो सकती है।

तो यह हो सकता है:

try dm := DecodeMsg(m)
try um := dm.SaveToDB()
try EmitEvent(um)

निम्नलिखित के बजाय ( @brynbellomy के उदाहरण से):

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

ऐसा लगता है कि यह बॉयलरप्लेट को कम करते हुए, बिना किसी संपादक या आईडीई सहायता के, उचित मात्रा में दृश्यता को बनाए रखेगा।

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

प्रस्ताव में यह उदाहरण शामिल है:

info := try(try(os.Open(file)).Stat())    // proposed try built-in

इसके बजाय यह हो सकता है:

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

यह अभी भी बॉयलरप्लेट में कमी है जो आज कोई लिख सकता है, भले ही प्रस्तावित सिंटैक्स जितना छोटा न हो। शायद यह काफी छोटा होगा?

@ elagergren-spideroak ने इस उदाहरण की आपूर्ति की:

try(try(try(to()).parse().this)).easily())

मुझे लगता है कि इसमें बेमेल माता-पिता हैं, जो शायद एक जानबूझकर बिंदु या हास्य का एक सूक्ष्म सा है, इसलिए मुझे यकीन नहीं है कि उस उदाहरण का इरादा 2 try या 3 try है। किसी भी घटना में, शायद इसे try से शुरू होने वाली 2-3 पंक्तियों में फैलाने की आवश्यकता होगी।

@thepudds , यह वही है जो मुझे अपनी पिछली टिप्पणी में मिल रहा था। सिवाय इसके कि दिया गया

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

करने के लिए एक स्पष्ट बात यह है कि try को एक try ब्लॉक के रूप में सोचें जहां एक से अधिक वाक्य कोष्ठक के भीतर रखे जा सकते हैं। तो उपरोक्त बन सकता है

try (
    f := os.Open(file)
    into := f.Stat()
)

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

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

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

अगली बात उन बयानों को अनुमति देना है जहां या तो कोई त्रुटि मान उत्पन्न नहीं हो रहा है या स्थानीय रूप से नियंत्रित किया जाता है। तो अब आप कह सकते हैं

try (
    f := os.Open(file)
    debug("f: %v\n", f) // debug returns nothing
    into := f.Stat()
)

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

try(try(try(to()).parse()).this)).easily())

जबकि मैं पूरी तरह से ठीक हूं

try to().parse().this().easily()

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

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

मैं कुछ हद तक कार्यक्रमों की पठनीयता के बारे में चिंतित था जहां try अन्य अभिव्यक्तियों के अंदर दिखाई देता है। इसलिए मैंने मानक पुस्तकालय पर grep "return .*err$" चलाया और यादृच्छिक रूप से ब्लॉक के माध्यम से पढ़ना शुरू कर दिया। 7214 परिणाम हैं, मैंने केवल दो सौ ही पढ़े हैं।

ध्यान देने वाली पहली बात यह है कि जहां try लागू होता है, यह इन सभी ब्लॉकों को थोड़ा अधिक पठनीय बनाता है।

दूसरी बात यह है कि इनमें से बहुत कम, 10 में 1 से कम, try को किसी अन्य अभिव्यक्ति के अंदर रखेंगे। विशिष्ट मामला x := try(...) या ^try(...)$ फ़ॉर्म का विवरण है।

यहां कुछ उदाहरण दिए गए हैं जहां try किसी अन्य अभिव्यक्ति के अंदर दिखाई देगा:

टेक्स्ट/टेम्पलेट

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

बन जाता है:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        return !try(le(arg1, arg2)), nil
}

टेक्स्ट/टेम्पलेट

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

हो जाता है

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                if x := v.MapIndex(try(prepareArg(index, v.Type().Key()))); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

(यह मैंने देखा सबसे संदिग्ध उदाहरण है)

रेगेक्सपी/वाक्यविन्यास:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

हो जाता है

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        c, t = try(nextRune(t))
        p.literal(c)
        ...
}

यह किसी अन्य अभिव्यक्ति के अंदर प्रयास का उदाहरण नहीं है, लेकिन मैं इसे कॉल करना चाहता हूं क्योंकि यह पठनीयता में सुधार करता है। यहां यह देखना बहुत आसान है कि c और t के मान if कथन के दायरे से बाहर रह रहे हैं।

नेट/http

नेट/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

बन जाता है:

        req.Header = Header(try(tp.ReadMIMEHeader())

डेटाबेस/एसक्यूएल

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

हो जाता है

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

डेटाबेस/एसक्यूएल

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

हो जाता है

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }

नेट/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

हो जाता है

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                return try(p.t.dialclientconn(addr, singleuse))
        }

नेट/http

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

हो जाता है

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

(यह मुझे वास्तव में पसंद है।)

नेट/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

हो जाता है

        hc = try(fr.ReadFrame()).(*http2ContinuationFrame)// guaranteed by checkFrameOrder

}

(अच्छा भी।)

शुद्ध :

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

हो जाता है

        if ctrlFn != nil {
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), try(newRawConn(fd))))
        }

शायद यह बहुत अधिक है, और इसके बजाय यह होना चाहिए:

        if ctrlFn != nil {
                c := try(newRawConn(fd))
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), c))
        }

कुल मिलाकर, मैं मानक पुस्तकालय कोड पर try के प्रभाव का काफी आनंद लेता हूं जिसे मैंने पढ़ा है।

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

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

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

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

यह एक अभिव्यक्ति के साथ यकीनन बेहतर होगा- try अगर ऐसे कई क्षेत्र थे जिन्हें try -ed होना था, लेकिन मैं अभी भी इस व्यापार के संतुलन को पसंद करता हूं

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

यह मूल रूप से इसके लिए सबसे खराब स्थिति है और यह ठीक दिखता है:

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

मैंने खुद से बहस की कि क्या if try कानूनी होगा या होना चाहिए, लेकिन मैं एक उचित स्पष्टीकरण के साथ नहीं आ सका कि यह क्यों नहीं होना चाहिए और यह यहां काफी अच्छा काम करता है:

func (f *http2Framer) endWrite() error {
        ...
        if try n := f.w.Write(f.wbuf); n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

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

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

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

func (f *http2Framer) endWrite() error {
        ...
        relay n := f.w.Write(f.wbuf)
        return checkShortWrite(n, len(f.wbuf))
}

यदि आप एक बयान का प्रयास करते हैं, तो आप यह इंगित करने के लिए ध्वज का उपयोग कर सकते हैं कि कौन सा वापसी मूल्य, और कौन सी क्रिया:

try c, @      := newRawConn(fd) // return
try c, <strong i="6">@panic</strong> := newRawConn(fd) // panic
try c, <strong i="7">@hname</strong> := newRawConn(fd) // invoke named handler
try c, <strong i="8">@_</strong>     := newRawConn(fd) // ignore, or invoke "ignored" handler if defined

कम से कम घबराहट और कार्यों को अनदेखा करने के लिए आपको अभी भी एक उप-अभिव्यक्ति वाक्यविन्यास की आवश्यकता है (रस ने कहा है कि यह एक आवश्यकता है)।

सबसे पहले, मैं लगभग 200 वास्तविक उदाहरणों को देखने के लिए समय निकालने और ऊपर उनके विचारशील लेखन के लिए समय निकालने के लिए @crawhaw की सराहना करता हूं।

दूसरा, @jimmyfrasche , यहां http2Framer उदाहरण के बारे में आपकी प्रतिक्रिया के बारे में:

मैंने खुद से बहस की कि क्या if try कानूनी होगा या होना चाहिए, लेकिन मैं एक उचित स्पष्टीकरण के साथ नहीं आ सका कि यह क्यों नहीं होना चाहिए और यह यहां काफी अच्छा काम करता है:

```
func (f *http2Framer) एंडराइट () त्रुटि {
...
अगर कोशिश n := fwWrite(f.wbuf); n!= लेन(f.wbuf) {
वापसी io.ErrShortWrite
}
वापसी शून्य
}

At least under what I was suggesting above in https://github.com/golang/go/issues/32437#issuecomment-500213884, under that proposal variation I would suggest `if try` is not allowed.

That `http2Framer` example could instead be:

func (f *http2Framer) एंडराइट () त्रुटि {
...
कोशिश n:= fwWrite(f.wbuf)
अगर n!= लेन(f.wbuf) {
वापसी io.ErrShortWrite
}
वापसी शून्य
}
`` That is one line longer, but hopefully still "light on the page". Personally, I think that (arguably) reads more cleanly, but more importantly it is easier to see the कोशिश करें'।

@deanveloper ने ऊपर https://github.com/golang/go/issues/32437#issuecomment -498932961 में लिखा है:

ऐसा लगता है कि किसी समारोह से लौटना एक "पवित्र" बात थी

वह विशिष्ट http2Framer उदाहरण उतना छोटा नहीं है जितना संभवतः हो सकता है। हालांकि, यह एक समारोह से अधिक "पवित्र" लौटता है यदि try एक लाइन पर पहली चीज होनी चाहिए।

@ क्रॉशॉ ने उल्लेख किया:

दूसरी बात यह है कि इनमें से बहुत कम, 10 में 1 से कम, किसी अन्य अभिव्यक्ति के अंदर प्रयास करेंगे। विशिष्ट मामला प्रपत्र x := try(...) या ^try(...)$ के विवरण हैं।

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

@jimmyfrasche

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

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

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

आपका पहला उदाहरण अच्छी तरह से दिखाता है कि मैं अभिव्यक्ति को दृढ़ता से क्यों पसंद करता हूं- try । आपके संस्करण में, मुझे कॉल के परिणाम को एक चर में le पर रखना होगा, लेकिन उस चर का कोई अर्थपूर्ण अर्थ नहीं है कि शब्द le पहले से ही अर्थ नहीं रखता है। तो ऐसा कोई नाम नहीं है जिसे मैं दे सकता हूं जो या तो अर्थहीन नहीं है (जैसे x ) या बेमानी (जैसे lessOrEqual )। अभिव्यक्ति के साथ- try , किसी मध्यवर्ती चर की आवश्यकता नहीं है, इसलिए यह समस्या उत्पन्न भी नहीं होती है।

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

मुझे पिछली कुछ पोस्टों के लिए अपना समर्थन देने में प्रसन्नता हो रही है जहां try (कीवर्ड) को लाइन की शुरुआत में ले जाया गया है। इसे वास्तव में return के समान दृश्य स्थान साझा करना चाहिए।

पुन: @jimmyfrasche का सुझाव try को कंपाउंड if स्टेटमेंट्स के भीतर अनुमति देने के लिए, ठीक उसी तरह की चीज है जो मुझे लगता है कि यहां कई लोग कुछ कारणों से बचने की कोशिश कर रहे हैं:

• यह दो अलग-अलग नियंत्रण प्रवाह तंत्रों को एक पंक्ति में मिलाता है
• try अभिव्यक्ति का वास्तव में पहले मूल्यांकन किया जाता है, और फ़ंक्शन को वापस करने का कारण बन सकता है, फिर भी यह if के बाद दिखाई देता है
• वे पूरी तरह से अलग त्रुटियों के साथ लौटते हैं, जिनमें से एक हम वास्तव में कोड में नहीं देखते हैं, और एक जो हम करते हैं
• यह कम स्पष्ट करता है कि try वास्तव में हैंडल नहीं किया गया है, क्योंकि ब्लॉक एक हैंडलर ब्लॉक की तरह दिखता है (भले ही यह एक पूरी तरह से अलग समस्या को संभाल रहा हो)

इस स्थिति को थोड़ा अलग कोण से देखा जा सकता है जो लोगों को try s को संभालने के लिए प्रेरित करता है। try / else सिंटैक्स को बाद की शर्तों को शामिल करने की अनुमति देने के बारे में (जो कि कई I/O फ़ंक्शंस के साथ एक सामान्य पैटर्न है जो err और n दोनों लौटाता है

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf) else err {
                return errors.Wrap(err, "error writing:")
        } else if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

उस मामले में जहां आप .Write द्वारा लौटाई गई त्रुटि को संभाल नहीं पाते हैं, फिर भी आपके पास एक स्पष्ट एनोटेशन होगा कि .Write त्रुटि हो सकती है (जैसा कि @thepudds द्वारा इंगित किया गया है):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

मैं दूसरा @daved की प्रतिक्रिया। मेरी राय में प्रत्येक उदाहरण जिसे @crawshaw हाइलाइट किया गया, कम स्पष्ट हो गया और try के परिणामस्वरूप अधिक त्रुटि प्रवण हो गया।

मुझे पिछली कुछ पोस्टों के लिए अपना समर्थन देने में प्रसन्नता हो रही है जहां try (कीवर्ड) को लाइन की शुरुआत में ले जाया गया है। इसे वास्तव में return के समान दृश्य स्थान साझा करना चाहिए।

इस बिंदु के लिए दो विकल्पों को देखते हुए और यह मानते हुए कि एक को चुना गया था और इस प्रकार भविष्य की संभावित विशेषताओं के लिए कुछ हद तक एक मिसाल कायम की गई थी:

ए।)

try f := os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

बी।)

f := try os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

दोनों में से कौन भविष्य में नए कीवर्ड उपयोग के लिए अधिक लचीलापन प्रदान करता है? _(इसका उत्तर मुझे नहीं पता क्योंकि मुझे संकलक लिखने की गहरी कला में महारत हासिल नहीं है।)_ क्या एक दृष्टिकोण दूसरे की तुलना में अधिक सीमित होगा?

@davecheney @daved @crawshaw
मैं इस पर डेव के साथ सहमत होना चाहता हूं: @ क्रॉशॉ के उदाहरणों में, बहुत सारे try स्टेटमेंट हैं जो लाइनों में गहरे एम्बेडेड हैं जिनमें बहुत सी अन्य चीजें चल रही हैं। निकास बिंदुओं को खोजना वास्तव में कठिन है। इसके अलावा, try माता-पिता कुछ उदाहरणों में चीजों को बहुत बुरी तरह से अव्यवस्थित करते हैं।

इस तरह रूपांतरित किए गए stdlib कोड का एक गुच्छा देखना बहुत उपयोगी है, इसलिए मैंने वही उदाहरण लिए हैं, लेकिन उन्हें वैकल्पिक प्रस्ताव के अनुसार फिर से लिखा है, जो अधिक प्रतिबंधात्मक है:

• try एक कीवर्ड के रूप में
• केवल एक try प्रति पंक्ति
• try एक पंक्ति की शुरुआत में होना चाहिए

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

टेक्स्ट/टेम्पलेट

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

बन जाता है:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

टेक्स्ट/टेम्पलेट

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

हो जाता है

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

रेगेक्सपी/वाक्यविन्यास:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

हो जाता है

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

नेट/http

नेट/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

बन जाता है:

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

डेटाबेस/एसक्यूएल

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

हो जाता है

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

डेटाबेस/एसक्यूएल

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

हो जाता है

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

नेट/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

हो जाता है

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

नेट/http
यह वास्तव में हमें कोई लाइन नहीं बचाता है, लेकिन मुझे यह बहुत स्पष्ट लगता है क्योंकि if err == nil एक अपेक्षाकृत असामान्य निर्माण है।

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

हो जाता है

func (f *http2Framer) endWrite() error {
        ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

नेट/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

हो जाता है

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
}

जाल:

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

हो जाता है

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@ James-lawrence https://github.com/golang/go/issues/32437#issuecomment -500116099 के जवाब में: मुझे याद नहीं है कि वैकल्पिक , err जैसे विचारों पर गंभीरता से विचार किया जा रहा है, नहीं। व्यक्तिगत रूप से मुझे लगता है कि यह एक बुरा विचार है, क्योंकि इसका मतलब है कि यदि कोई फ़ंक्शन पिछला error पैरामीटर जोड़ने के लिए बदलता है, तो मौजूदा कोड संकलित करना जारी रखेगा, लेकिन बहुत अलग तरीके से कार्य करेगा।

त्रुटियों को संभालने के लिए defer का उपयोग करना बहुत मायने रखता है, लेकिन इससे त्रुटि और एक नए प्रकार के if err != nil बॉयलरप्लेट को नाम देने की आवश्यकता होती है।

बाहरी संचालकों को यह करने की आवश्यकता है:

func handler(err *error) {
  if *err != nil {
    *err = handle(*err)
  }
} 

जो की तरह इस्तेमाल हो जाता है

defer handler(&err)

बाहरी संचालकों को केवल एक बार लिखा जाना चाहिए, लेकिन कई त्रुटि प्रबंधन कार्यों के दो संस्करण होने चाहिए: एक को स्थगित किया जाना चाहिए और दूसरा नियमित रूप से उपयोग किया जाना चाहिए।

आंतरिक संचालकों को यह करने की आवश्यकता है:

defer func() {
  if err != nil {
    err = handle(err)
  }
}()

दोनों ही मामलों में, बाहरी फ़ंक्शन की त्रुटि को एक्सेस करने के लिए नामित किया जाना चाहिए।

जैसा कि मैंने पहले धागे में उल्लेख किया है, इसे एक ही समारोह में सारणित किया जा सकता है:

func catch(err *error, handle func(error) error) {
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

यह nil हैंडलर funcs की अस्पष्टता पर @griesemer की चिंता से दूर चलता है और इसका अपना defer और func(err error) error बॉयलरप्लेट है, इसके अलावा err नाम भी है

यदि try एक कीवर्ड के रूप में समाप्त होता है, तो यह एक catch कीवर्ड होने का भी अर्थ हो सकता है, जिसका वर्णन नीचे भी किया जा सकता है।

सिंटैक्टिक रूप से, यह handle जैसा होगा:

catch err {
  return handleThe(err)
}

अर्थात्, यह उपरोक्त आंतरिक हैंडलर कोड के लिए चीनी होगी:

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

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

catch पर try के समान प्रतिबंध होगा कि यह एक ऐसे फ़ंक्शन में होना चाहिए जिसमें अंतिम त्रुटि वापसी हो, क्योंकि वे दोनों चीनी हैं जो उस पर निर्भर हैं।

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

जटिल त्रुटि प्रबंधन के लिए catch का उपयोग न करने की आवश्यकता हो सकती है क्योंकि इसके लिए try का उपयोग न करने की आवश्यकता हो सकती है।

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

catch err {
  log.Print(err)
  return err
}

या बस सभी लौटाई गई त्रुटियों को लपेटना:

catch err {
  return fmt.Errorf("foo: %w", err)
}

@ianlancetaylor

_" मुझे लगता है कि यह एक बुरा विचार है, क्योंकि इसका मतलब है कि यदि कोई फ़ंक्शन पिछला error पैरामीटर जोड़ने के लिए बदलता है, तो मौजूदा कोड संकलित करना जारी रखेगा, लेकिन बहुत अलग तरीके से कार्य करेगा।"_

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

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

क्या आप एक ऐसे उदाहरण के बारे में सोच सकते हैं जहां कोई व्यक्ति वापसी मूल्य जोड़ने के लिए हस्ताक्षर बदलेगा? मेरे लिए वे आम तौर पर _ "मुझे नहीं पता था कि कोई त्रुटि होगी" की श्रेणी में आ गए हैं या _ "मैं आलसी महसूस कर रहा हूं और प्रयास में नहीं जाना चाहता क्योंकि त्रुटि शायद नहीं होगी।" _

उन दोनों मामलों में मैं एक त्रुटि वापसी जोड़ सकता हूं क्योंकि यह स्पष्ट हो जाता है कि एक त्रुटि को संभालने की आवश्यकता है। जब ऐसा होता है, अगर मैं हस्ताक्षर नहीं बदल सकता क्योंकि मैं अपने पैकेज का उपयोग करने वाले अन्य डेवलपर्स के लिए संगतता को तोड़ना नहीं चाहता, तो क्या करना चाहिए? मेरा अनुमान है कि अधिकांश समय त्रुटि होगी और कोड जिसे func कहा जाता है जो त्रुटि वापस नहीं करता है, बहुत अलग तरीके से कार्य करेगा, _anyway._

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

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

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

उदाहरण के लिए, एक पैकेज त्रुटि हैंडलर जोड़ने पर विचार करें जिसे त्रुटियों को अनदेखा करने में सक्षम होने से पहले सेट करना चाहिए?

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

हम गोफर एक अपवाद को फेंकने के बजाय एक त्रुटि को वापस करने में डूब गए हैं, इसलिए मेरे पास सवाल यह है कि _ "हमें हर फ़ंक्शन से त्रुटियां क्यों नहीं लौटानी चाहिए?"_ हम हमेशा ऐसा नहीं करते हैं क्योंकि त्रुटि प्रबंधन के बिना कोड लिखना है इसके साथ कोडिंग की तुलना में अधिक सुविधाजनक। इसलिए जब हम सोचते हैं कि हम इससे दूर हो सकते हैं तो हम त्रुटि प्रबंधन को छोड़ देते हैं। लेकिन अक्सर हम गलत अनुमान लगाते हैं।

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

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

try एक कीवर्ड के रूप में निश्चित रूप से पठनीयता (बनाम एक फ़ंक्शन कॉल) में मदद करता है और कम जटिल लगता है। @brynbellomy @crawshaw उदाहरणों को लिखने के लिए समय निकालने के लिए धन्यवाद।

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

यह शायद एक नया विचार नहीं है ... लेकिन त्रुटि प्रतिक्रिया विकी में प्रस्तावों को स्किम करने के बाद, मुझे यह नहीं मिला (इसका मतलब यह नहीं है कि यह वहां नहीं है)

सशर्त वापसी पर छोटा प्रस्ताव

अंश:

err, thing := newThing(name)
refuse nil, err

मैंने इसे "वैकल्पिक विचारों" के तहत विकी में भी जोड़ा

कुछ न करना भी एक बहुत ही उचित विकल्प लगता है।

@alexhornbake जो मुझे थोड़ा अलग विचार देता है जो अधिक उपयोगी होगा

assert(nil, err)
assert(len(a), len(b))
assert(true, condition)
assert(expected, given)

इस तरह यह न केवल त्रुटि जाँच पर लागू होगा, बल्कि कई प्रकार की तर्क त्रुटियों पर भी लागू होगा।

दिए गए को एक त्रुटि में लपेटा जाएगा और वापस कर दिया जाएगा।

@alexhornbake

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

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

        req.Header = Header(try(tp.ReadMIMEHeader())

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

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

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

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

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }   

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

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

@daved मुझे यकीन नहीं है कि मैं अनुसरण करता हूं। क्या आप नाम नापसंद करते हैं, या विचार नापसंद करते हैं?

वैसे भी, मैंने इसे यहां एक विकल्प के रूप में पोस्ट किया है ... यदि कानूनी रुचि है तो मैं चर्चा के लिए एक नया मुद्दा खोल सकता हूं, इस धागे को प्रदूषित नहीं करना चाहता (शायद बहुत देर हो चुकी है?) मूल विचार पर अंगूठे ऊपर/नीचे देंगे हमें एक भावना... बेशक वैकल्पिक नामों के लिए खुला है। महत्वपूर्ण हिस्सा "असाइनमेंट को संभालने की कोशिश किए बिना सशर्त वापसी" है।

हालांकि मुझे @jimmyfrasche द्वारा कैच प्रस्ताव पसंद है, मैं एक विकल्प प्रस्तावित करना चाहता हूं:
go handler fmt.HandleErrorf("copy %s %s", src, dst)
के बराबर होगा:
go defer func(){ if(err != nil){ fmt.HandleErrorf(&err,"copy %s %s", src, dst) } }()
जहां त्रुटि प्रकार त्रुटि के साथ अंतिम नामित वापसी मूल्य है। हालांकि, हैंडलर का उपयोग तब भी किया जा सकता है जब रिटर्न वैल्यू का नाम नहीं दिया जाता है। अधिक सामान्य मामले की भी अनुमति दी जाएगी:
go handler func(err *error){ *err = fmt.Errorf("foo: %w", *err) }() `
मेरे पास नामित रिटर्न वैल्यू (जो पकड़ हल नहीं करता है) का उपयोग करने के साथ मुख्य समस्या यह है कि गलती अनावश्यक है। fmt.HandleErrorf जैसे हैंडलर को कॉल स्थगित करते समय, त्रुटि वापसी मान के सूचक को छोड़कर कोई उचित पहला तर्क नहीं है, उपयोगकर्ता को गलती करने का विकल्प क्यों दे रहा है?

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

@yiyus catch , जैसा कि मैंने परिभाषित किया है कि इसे $#$2 catch #$ वाले फ़ंक्शन पर नामित करने के लिए err की आवश्यकता नहीं है।

catch err { में, err वह है जिसे catch ब्लॉक के भीतर त्रुटि नाम दिया गया है। यह एक फ़ंक्शन पैरामीटर नाम की तरह है।

इसके साथ, fmt.HandleErrorf जैसी किसी चीज़ की कोई आवश्यकता नहीं है क्योंकि आप केवल नियमित fmt.Errorf का उपयोग कर सकते हैं:

func f() error {
  catch err {
    return fmt.Errorf("foo: %w", err)
  }
  return errors.New("bar")
}

जो एक त्रुटि देता है जो foo: bar के रूप में प्रिंट करता है।

मुझे यह दृष्टिकोण पसंद नहीं है, क्योंकि:

• try() फ़ंक्शन कॉल पैरेंट फ़ंक्शन में कोड निष्पादन को बाधित करता है।
• कोई return कीवर्ड नहीं है, लेकिन कोड वास्तव में वापस आ जाता है।

हैंडलर करने के कई तरीके प्रस्तावित किए जा रहे हैं, लेकिन मुझे लगता है कि वे अक्सर दो प्रमुख आवश्यकताओं को याद करते हैं:

1. इसे if x, err := thingie(); err != nil { handle(err) } से काफी अलग और बेहतर होना चाहिए। मुझे लगता है कि try x := thingie else err { handle(err) } की तर्ज पर सुझाव उस बार से मेल नहीं खाते। क्यों न केवल if कहें?

2. यह defer की मौजूदा कार्यक्षमता के लिए ऑर्थोगोनल होना चाहिए। यही है, यह इतना अलग होना चाहिए कि यह स्पष्ट हो कि प्रस्तावित हैंडलिंग तंत्र को अपने आप में अजीब कोने के मामलों को बनाए बिना जब हैंडल और डिफर इंटरेक्शन की आवश्यकता होती है।

कृपया इन desiderata को ध्यान में रखें क्योंकि हम try /handle के लिए वैकल्पिक तंत्र पर चर्चा करते हैं।

@carlmjohnson मुझे आपके बिंदु 2 के बारे में @jimmyfrasche का catch विचार पसंद है - यह defer के लिए सिंटैक्स चीनी है जो 2 लाइनों को बचाता है और आपको त्रुटि वापसी मान (जो में) नाम देने से बचने देता है यदि आप पहले से नहीं थे तो आपको अन्य सभी के नाम की भी आवश्यकता होगी)। यह defer के साथ एक ऑर्थोगोनैलिटी मुद्दा नहीं उठाता है , क्योंकि यह defer है।

@ubombi ने जो कहा उसकी गूंज:

try() फ़ंक्शन कॉल पैरेंट फ़ंक्शन में कोड निष्पादन को बाधित करता है।; कोई वापसी कीवर्ड नहीं है, लेकिन कोड वास्तव में वापस आ जाता है।

रूबी में, प्रोसेस और लैम्ब्डा इस बात का उदाहरण हैं कि try क्या करता है... एक प्रो कोड का एक ब्लॉक है जिसका रिटर्न स्टेटमेंट ब्लॉक से ही नहीं, बल्कि कॉलर से आता है।

यह वही है जो try करता है ... यह सिर्फ एक पूर्व-परिभाषित रूबी प्रो है।

मुझे लगता है कि अगर हम उस मार्ग पर जाने वाले थे, तो शायद हम वास्तव में उपयोगकर्ता को proc functions की शुरुआत करके अपने स्वयं के try फ़ंक्शन को परिभाषित करने दे सकते हैं

मैं अभी भी if err != nil पसंद करता हूं, क्योंकि यह अधिक पठनीय है लेकिन मुझे लगता है कि try अधिक फायदेमंद होगा यदि उपयोगकर्ता अपनी खरीद को परिभाषित करता है:

proc try(err *error, msg string) {
  if *err != nil {
    *err = fmt.Errorf("%v: %w", msg, *err)
    return
  }
}

और फिर आप इसे कॉल कर सकते हैं:

func someFunc() (string, error) {
  err := doSomething()
  try(&err, "someFunc failed")
}

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

यह मूल Go2 प्रस्ताव में handle {} क्लॉज से भी बेहतर है क्योंकि आप इसे पूरे कोडबेस के लिए केवल एक बार परिभाषित कर सकते हैं, प्रत्येक फ़ंक्शन में नहीं।

पठनीयता के लिए एक विचार यह है कि एक func() और एक proc() को अलग-अलग कहा जा सकता है जैसे func() और proc!() ताकि एक प्रोग्रामर जानता है कि एक proc कॉल वास्तव में वापस आ सकता है कॉलिंग फ़ंक्शन।

@ मारवान-एट-वर्क, आपके उदाहरण में try(err, "someFunc failed") try(&err, "someFunc failed") नहीं होना चाहिए?

@dpinela सुधार के लिए धन्यवाद, कोड अपडेट किया :)

जिस सामान्य प्रथा को हम यहां ओवरराइड करने का प्रयास कर रहे हैं, वह यह है कि कई भाषाओं में मानक स्टैक अनइंडिंग एक अपवाद में सुझाव देता है, (और इसलिए "कोशिश" शब्द का चयन किया गया था ...)
लेकिन अगर हम केवल एक फ़ंक्शन (... कोशिश () या अन्य) की अनुमति दे सकते हैं जो ट्रेस में दो स्तरों को पीछे छोड़ देगा, तो

try := handler(err error) {     //which corelates with - try := func(err error) 
   if err !=nil{
       //do what ever you want to do when there's an error... log/print etc
       return2   //2 levels
   }
} 

और फिर एक कोड जैसे
f := try(os.Open(filename))
जैसा कि प्रस्ताव सलाह देता है, ठीक वैसा ही कर सकता है, लेकिन इसके एक फ़ंक्शन (या वास्तव में एक "हैंडलर फ़ंक्शन") के रूप में, डेवलपर के पास फ़ंक्शन क्या करता है, यह विभिन्न मामलों में त्रुटि को कैसे प्रारूपित करता है, इस पर अधिक नियंत्रण होगा, एक समान हैंडलर का उपयोग करें चारों ओर हर बार fmt.Errorf ("एरर ओपनिंग फाइल %s ....") लिखने के बजाय os.Open को हैंडल करने के लिए कोड।
यह त्रुटि प्रबंधन को भी मजबूर करेगा जैसे कि "कोशिश" परिभाषित नहीं किया जाएगा - यह एक संकलन समय त्रुटि है।

@guybrand इस तरह के दो-स्तरीय रिटर्न return2 (या "गैर-स्थानीय रिटर्न" के रूप में सामान्य अवधारणा को स्मॉलटाक में कहा जाता है) एक अच्छा सामान्य-उद्देश्य तंत्र होगा (# 32473 में @mikeschinkel द्वारा भी सुझाया गया) . लेकिन ऐसा लगता है कि आपके सुझाव में अभी भी try की आवश्यकता है, इसलिए मुझे return2 का कोई कारण नहीं दिख रहा है - try केवल return कर सकता है try भी लिख सकता है, लेकिन यह मनमाने हस्ताक्षर के लिए संभव नहीं है।

@griesemer

_"इसलिए मुझे return2 का कोई कारण नहीं दिख रहा है - try बस return कर सकता है।"_

एक कारण - जैसा कि मैंने #32473 _(संदर्भ के लिए धन्यवाद)_ में बताया - $#$ return के अलावा break और continue के कई स्तरों की अनुमति देना होगा।

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

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

1) सामान्य तौर पर, try कार्यक्षमता के लिए बिल्ट-इन का उपयोग करना एक बुरा विकल्प माना जाता है: यह देखते हुए कि यह नियंत्रण प्रवाह को प्रभावित करता है, इसे _at कम से कम_ एक कीवर्ड होना चाहिए ( @carloslenz "इसे बिना बयान के बनाना पसंद करता है कोष्ठक"); try एक अभिव्यक्ति के रूप में एक अच्छा विचार नहीं लगता है, यह पठनीयता को नुकसान पहुंचाता है ( @ChrisHines , @jimmyfrasche), वे " return के बिना रिटर्न" हैं। @brynbellomy ने पहचानकर्ता के रूप में उपयोग किए गए try का वास्तविक विश्लेषण किया; बहुत कम प्रतिशत-वार प्रतीत होता है, इसलिए बहुत अधिक कोड को प्रभावित करने वाले कीवर्ड रूट w/o पर जाना संभव हो सकता है।

2) @crawhaw ने एसटीडी लाइब्रेरी से कुछ सौ उपयोग के मामलों का विश्लेषण करने में कुछ समय लिया और इस निष्कर्ष पर पहुंचे कि प्रस्तावित try के रूप में लगभग हमेशा पठनीयता में सुधार हुआ। @jimmyfrasche विपरीत निष्कर्ष पर आया।

3) एक अन्य विषय यह है कि त्रुटि सजावट के लिए defer का उपयोग करना आदर्श नहीं है। @josharian बताते हैं कि defer हमेशा फंक्शन रिटर्न पर चलता है, लेकिन अगर वे त्रुटि सजावट के लिए यहां हैं, तो हम केवल उनके शरीर की परवाह करते हैं यदि कोई त्रुटि है, जो भ्रम का स्रोत हो सकता है।

4) प्रस्ताव में सुधार के लिए कई लोगों ने सुझाव लिखे। @zeebo , @patrick-nyt gofmt के समर्थन में हैं जो एक ही लाइन पर सरल if स्टेटमेंट को फ़ॉर्मेट करते हैं (और यथास्थिति से खुश रहें)। @jargv ने सुझाव दिया कि try() (बिना तर्कों के) वर्तमान में "लंबित" त्रुटि के लिए एक सूचक लौटा सकता है, जो त्रुटि परिणाम को नाम देने की आवश्यकता को हटा देगा ताकि किसी के पास defer में इसका उपयोग हो। @masterada ने इसके बजाय errorfunc() का उपयोग करने का सुझाव दिया। @velovix ने 2-तर्क try के विचार को पुनर्जीवित किया जहां दूसरा तर्क एक त्रुटि हैंडलर होगा।

@klaidliadon , @networkimprov विशेष "असाइनमेंट ऑपरेटरों" के पक्ष में हैं जैसे f, # := os.Open() के बजाय try में। @networkimprov ने ऐसे दृष्टिकोणों की जांच के लिए एक अधिक व्यापक वैकल्पिक प्रस्ताव दायर किया (देखें अंक #32500)। @mikeschinkel ने दो नई सामान्य प्रयोजन भाषा सुविधाओं को पेश करने का सुझाव देते हुए एक वैकल्पिक प्रस्ताव भी दायर किया, जिसका उपयोग त्रुटि-विशिष्ट try के बजाय त्रुटि प्रबंधन के लिए भी किया जा सकता है (समस्या #32473 देखें)। @josharian ने पिछले साल गोफरकॉन में चर्चा की गई एक संभावना को पुनर्जीवित किया, जहां try एक त्रुटि पर वापस नहीं आता है, बल्कि error (वैकल्पिक रूप से) नामक लेबल पर कूदता है ( goto के साथ) , try लक्ष्य लेबल का नाम ले सकता है)।

5) एक कीवर्ड के रूप में try के विषय पर विचारों की दो पंक्तियाँ सामने आई हैं। @brynbellomy ने एक ऐसे संस्करण का सुझाव दिया जो वैकल्पिक रूप से एक हैंडलर निर्दिष्ट कर सकता है:

a, b := try f()
a, b := try f() else err { /* handle error */ }

@thepudds एक कदम आगे जाता है और लाइन की शुरुआत में try का सुझाव देता है, try को $#$24 return try के समान दृश्यता देता है:

try a, b := f()

ये दोनों defer के साथ काम कर सकते हैं।

@griesemer

@Mikeschinkel #32473 के रेफरी के लिए धन्यवाद, इसमें बहुत कुछ समान है।

के बारे में

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

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

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

आशा है कि मैं जल्द ही कुछ दिलचस्प परिणाम साझा कर सकूंगा।

अंत में - अद्भुत काम और धैर्य के लिए धन्यवाद!

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

try a, b := f() else err { return fmt.Errorf("Decorated: %s", err); }
if a,b, err :=f;  err != nil { return fmt.Errorf("Decorated: %s", err); }
try a, b := f()
if a,b, err :=f;  err != nil { return err; }

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

try else के संबंध में, मुझे लगता है कि सशर्त त्रुटि कार्य fmt.HandleErrorf (संपादित करें: मुझे लगता है कि इनपुट शून्य होने पर यह शून्य हो जाता है) प्रारंभिक टिप्पणी में ठीक काम करता है इसलिए else जोड़ना अनावश्यक है।

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

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

मैं @daved से भी सहमत हूं कि नाम उचित नहीं है। आखिरकार, हम यहां जो हासिल करने की कोशिश कर रहे हैं वह एक संरक्षित असाइनमेंट है, तो क्यों न स्विफ्ट में guard का उपयोग करें और else क्लॉज को वैकल्पिक बनाएं? कुछ इस तरह

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

जहां Identifier त्रुटि चर नाम निम्नलिखित Block में बाध्य है। else खंड के साथ, बस वर्तमान फ़ंक्शन से वापस आएं (और यदि आवश्यक हो तो त्रुटियों को सजाने के लिए एक स्थगित हैंडलर का उपयोग करें)।

मुझे शुरू में else क्लॉज पसंद नहीं आया क्योंकि यह सामान्य असाइनमेंट के आसपास सिर्फ सिंटैक्टिक शुगर है, उसके बाद if err != nil है, लेकिन कुछ उदाहरण देखने के बाद, यह सिर्फ समझ में आता है: guard का उपयोग करना

संपादित करें: कुछ ने किसी भी तरह अलग त्रुटि हैंडलर निर्दिष्ट करने के लिए catch जैसी चीजों का उपयोग करने का सुझाव दिया। मुझे else समान रूप से अर्थपूर्ण रूप से व्यवहार्य लगता है और यह पहले से ही भाषा में है।

जबकि मुझे कोशिश-और-कथन पसंद है, इस वाक्यविन्यास के बारे में कैसे?

a, b, (err) := func() else { return err }

अभिव्यक्ति try - else एक टर्नरी ऑपरेटर है।

a, b := try f() else err { ... }
fmt.Println(try g() else err { ... })`

कथन try - else एक if कथन है।

try a, b := f() else err { ... }
// (modulo scope of err) same as
a, b, err := f()
if err != nil { ... }

एक वैकल्पिक हैंडलर के साथ निर्मित try या तो एक सहायक फ़ंक्शन (नीचे) के साथ प्राप्त किया जा सकता है या try का उपयोग नहीं किया जा सकता है (चित्रित नहीं, हम सभी जानते हैं कि यह कैसा दिखता है)।

a, b := try(f(), decorate)
// same as
a, b := try(g())
// where g is
func g() (whatever, error) {
  x, err := f()
  if err != nil {
    try(decorate(err))
  }
  return x, nil
}

तीनों ने बॉयलरप्लेट पर कटौती की और त्रुटियों की गुंजाइश रखने में मदद की।

यह बिल्टिन try के लिए सबसे अधिक बचत देता है लेकिन इसमें डिज़ाइन दस्तावेज़ में उल्लिखित समस्याएं हैं।

कथन try - else के लिए, यह $#$ try $#$ के बजाय if का उपयोग करने पर एक लाभ प्रदान करता है। लेकिन लाभ इतना मामूली है कि मुझे इसे खुद को सही ठहराते हुए देखने में मुश्किल होती है, हालांकि मुझे यह पसंद है।

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

सभी त्रुटियों को समान रूप से संभालना defer में किया जा सकता है। यदि प्रत्येक else ब्लॉक में एक ही त्रुटि प्रबंधन किया जा रहा है जो थोड़ा दोहराव है:

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

मैं निश्चित रूप से जानता हूं कि ऐसे समय होते हैं जब एक निश्चित त्रुटि के लिए विशेष प्रबंधन की आवश्यकता होती है। वे उदाहरण हैं जो मेरी स्मृति में बने रहते हैं। लेकिन, अगर ऐसा होता है, तो कहें, 100 में से 1 बार, क्या try सरल रखना बेहतर नहीं होगा और उन स्थितियों में try का उपयोग न करें? दूसरी ओर, यदि यह 10 में से 1 बार अधिक है, तो else /handler जोड़ना अधिक उचित लगता है।

यह देखना दिलचस्प होगा कि कितनी बार try बिना else /हैंडलर बनाम try के साथ else /हैंडलर उपयोगी होगा, हालांकि डेटा इकट्ठा करना आसान नहीं है।

मैं @jimmyfrasche की हालिया टिप्पणी पर विस्तार करना चाहता हूं।

इस प्रस्ताव का लक्ष्य बॉयलरप्लेट को कम करना है

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

यह कोड पढ़ने में आसान है। यह भाषा का विस्तार करने के लायक है अगर हम बॉयलरप्लेट में काफी कमी हासिल कर सकते हैं। जब मैं कुछ ऐसा देखता हूँ

    try a, b := f() else err { return nil, err }

मैं मदद नहीं कर सकता लेकिन महसूस करता हूं कि हम इतना बचत नहीं कर रहे हैं। हम तीन पंक्तियों को सहेज रहे हैं, जो अच्छा है, लेकिन मेरी गिनती से हम 56 से 46 वर्णों को कम कर रहे हैं। यह बहुत नहीं है। से तुलना

    a, b := try(f())

जो 56 से 18 वर्णों में कटौती करता है, एक बहुत अधिक महत्वपूर्ण कमी। और जबकि try कथन नियंत्रण के प्रवाह के संभावित परिवर्तन को अधिक स्पष्ट बनाता है, कुल मिलाकर मुझे यह कथन अधिक पठनीय नहीं लगता है। हालांकि प्लस साइड पर try स्टेटमेंट त्रुटि को एनोटेट करना आसान बनाता है।

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

दूसरों की तरह, मैं उदाहरणों के लिए @crawshaw को धन्यवाद देना चाहता हूं।

उन उदाहरणों को पढ़ते समय, मैं लोगों को ऐसी मानसिकता अपनाने का प्रयास करने के लिए प्रोत्साहित करता हूं जिसमें आप try फ़ंक्शन के कारण नियंत्रण के प्रवाह के बारे में चिंता न करें। मेरा मानना ​​​​है, शायद गलत तरीके से, कि नियंत्रण का प्रवाह जल्दी ही उन लोगों के लिए दूसरी प्रकृति बन जाएगा जो भाषा जानते हैं। सामान्य स्थिति में, मेरा मानना ​​है कि लोग इस बात की चिंता करना बंद कर देंगे कि त्रुटि के मामले में क्या होता है। try पर ग्लेज़िंग करते हुए उन उदाहरणों को पढ़ने का प्रयास करें जैसे आप पहले से ही if err != nil { return err } पर ग्लेज़ कर चुके हैं।

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

1. इसके लिए तर्क बॉयलर प्लेट कोड को संभालने में त्रुटि को कम करना प्रतीत होता है। IMHO यह कोड को "अस्वीकार" करता है लेकिन यह वास्तव में जटिलता को दूर नहीं करता है; यह सिर्फ इसे अस्पष्ट करता है। यह एक कारण के लिए पर्याप्त मजबूत नहीं लगता है। जाओ"सिंटैक्स ने समवर्ती धागे को शुरू करते हुए खूबसूरती से कब्जा कर लिया। मुझे उस तरह का "आह!" यहाँ महसूस नहीं हो रहा है। यह सही नहीं लगता है। लागत/लाभ अनुपात काफी बड़ा नहीं है।

2. इसका नाम इसके कार्य को नहीं दर्शाता है। अपने सरलतम रूप में, यह क्या करता है: "यदि कोई फ़ंक्शन एक त्रुटि देता है, तो कॉलर से एक त्रुटि के साथ वापस आ जाता है" लेकिन वह बहुत लंबा है :-) कम से कम एक अलग नाम की आवश्यकता है।

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

4. और फिर भी मुझे विश्वास है कि एक बेहतर तरीका संभव हो सकता है। अभी कोशिश करने से वह विकल्प बंद हो जाएगा।

@ianlancetaylor
अगर मैं "अन्य प्रयास करें" प्रस्ताव को सही ढंग से समझता हूं, तो ऐसा लगता है कि else ब्लॉक वैकल्पिक है, और उपयोगकर्ता द्वारा प्रदान की जाने वाली हैंडलिंग के लिए आरक्षित है। आपके उदाहरण में try a, b := f() else err { return nil, err } else क्लॉज वास्तव में बेमानी है, और पूरी अभिव्यक्ति को केवल try a, b := f() के रूप में लिखा जा सकता है

मैं @ianlancetaylor से सहमत हूं,
पठनीयता और बॉयलरप्लेट दो मुख्य चिंताएं हैं और शायद ड्राइव करने के लिए
गो 2.0 त्रुटि प्रबंधन (हालांकि मैं कुछ अन्य महत्वपूर्ण चिंताओं को जोड़ सकता हूं)

इसके अलावा, कि वर्तमान

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

अत्यधिक पठनीय है।
और जब से मुझे विश्वास है

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

लगभग पठनीय है, फिर भी इसका दायरा "मुद्दे" था, शायद a

ifErr a, b, err := f() {
    return nil, err
}

वह केवल ; ग़लती != शून्य भाग, और कोई दायरा नहीं बनाएगा, या

उसी प्रकार

ए, बी, एरर का प्रयास करें: = एफ () {
वापसी शून्य, त्रुटि
}

अतिरिक्त दो पंक्तियाँ रखता है, लेकिन फिर भी पठनीय है।

मंगलवार को, 11 जून 2019, 20:19 दिमित्री मैट्रेनिचेव, नोटिफिकेशन @github.com
लिखा था:

@ianlancetaylor https://github.com/ianlancetaylor
अगर मैं "अन्य प्रयास करें" प्रस्ताव को सही ढंग से समझता हूं, तो ऐसा लगता है कि अन्य ब्लॉक
वैकल्पिक है, और उपयोगकर्ता द्वारा प्रदान की जाने वाली हैंडलिंग के लिए आरक्षित है। आपके उदाहरण में
कोशिश ए, बी: = एफ () और गलती {वापसी शून्य, गलती} अन्य खंड वास्तव में है
बेमानी, और पूरी अभिव्यक्ति को केवल कोशिश ए, बी: = के रूप में लिखा जा सकता है
एफ()

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH93Z94#VGOORPWSZ
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALNCNFSM4HTGCZ7Q
.

@ianlancetaylor

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

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

@ianlancetaylor इकोइंग @DmitriyMV , else ब्लॉक वैकल्पिक होगा। मुझे एक उदाहरण में फेंक दें जो दोनों को दिखाता है (और वास्तविक कोड में गैर-संभालने वाले try ब्लॉक के सापेक्ष अनुपात के संदर्भ में निशान से बहुत दूर नहीं लगता है):

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    headRef, err := r.Head()
    if err != nil {
        return err
    }

    parentObjOne, err := headRef.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentCommitOne, err := parentObjOne.AsCommit()
    if err != nil {
        return err
    }

    parentCommitTwo, err := parentObjTwo.AsCommit()
    if err != nil {
        return err
    }

    treeOid, err := index.WriteTree()
    if err != nil {
        return err
    }

    tree, err := r.LookupTree(treeOid)
    if err != nil {
        return err
    }

    remoteBranchName, err := remoteBranch.Name()
    if err != nil {
        return err
    }

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    if err != nil {
        return err
    }
    return nil
}

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()
    try userName, userEmail := r.UserIdentityFromConfig() else err {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    try r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return nil
}

जबकि try / else पैटर्न कंपाउंड if पर कई वर्णों को सहेजता नहीं है, यह करता है:

• हैंडल न किए गए try . के साथ त्रुटि प्रबंधन सिंटैक्स को एकीकृत करें
• एक नज़र में यह स्पष्ट करें कि एक सशर्त ब्लॉक एक त्रुटि स्थिति को संभाल रहा है
• हमें उस स्कोपिंग अजीबता को कम करने का मौका दें जो कंपाउंड if s से ग्रस्त है

हालांकि, बिना क्रिया के try सबसे आम होने की संभावना है।

@ianlancetaylor

ग्लेज़िंग ओवर के दौरान उन उदाहरणों को पढ़ने का प्रयास करें, जैसे कि आप पहले से ही ग्लेज़िंग कर रहे हैं अगर गलती! = शून्य {वापसी गलती}।

मुझे नहीं लगता कि यह संभव/समानता योग्य है। यह गुम है कि एक कोशिश एक भीड़-भाड़ वाली रेखा में मौजूद है, या यह वास्तव में क्या लपेटता है, या कि एक पंक्ति में कई उदाहरण हैं ...

@ianlancetaylor

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

मेरी आँखें if err != nil { return err } से अधिक चमक सकती हैं, लेकिन साथ ही यह अभी भी स्पष्ट रूप से और तुरंत पंजीकृत हो जाती है।

मुझे try -स्टेटमेंट वैरिएंट के बारे में जो पसंद है, वह यह है कि यह बॉयलरप्लेट को कम करता है लेकिन इस तरह से दोनों को चमकाना आसान है लेकिन याद करना मुश्किल है।

इसका मतलब यहाँ या वहाँ एक अतिरिक्त रेखा हो सकती है लेकिन यह अभी भी यथास्थिति से कम रेखाएँ हैं।

@brynbellomy

1. आप ऐसे कार्यों को संभालने की पेशकश कैसे करते हैं जो कई मान लौटाते हैं, जैसे:
   func createMergeCommit(r *repo.Repo, index *git.Index, Remote *git.Remote, RemoteBranch *git.Branch) (हैश, त्रुटि) {
2. आप उस सही लाइन का पता कैसे लगाएंगे जिसने त्रुटि लौटाई है
3. दायरे के मुद्दे को छोड़कर (जिसे अन्य तरीकों से हल किया जा सकता है), मुझे यकीन नहीं है

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {

    if headRef, err := r.Head(); err != nil {
        return err
    } else if parentObjOne, err := headRef.Peel(git.ObjectCommit); err != nil {
        return err
    } else parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit); err != nil {
        return err
    } ...

पठनीयता के लिहाज से इतना अलग नहीं है, फिर भी (या fmt.Errorf ("हेड प्राप्त करने में त्रुटि:% s", err.Error() ) आपको आसानी से संशोधित करने और अतिरिक्त डेटा देने की अनुमति देता है।

क्या अभी भी एक नाग है

1. फिर से जांचना पड़ रहा है; गलती!= शून्य
2. त्रुटि को वापस करना जैसे कि हम अतिरिक्त जानकारी नहीं देना चाहते हैं - जो कुछ मामलों में एक अच्छा अभ्यास नहीं है, क्योंकि आप उस फ़ंक्शन पर निर्भर हैं जिसे आप "अच्छी" त्रुटि को प्रतिबिंबित करने के लिए कहते हैं जो "क्या गलत हुआ" पर संकेत देगा ", फ़ाइल के मामलों में। खोलें, बंद करें, निकालें, डीबी फ़ंक्शंस इत्यादि कई फ़ंक्शन कॉल एक ही त्रुटि लौटा सकते हैं (हम तर्क दे सकते हैं कि इसका मतलब है कि डेवलपर ने त्रुटि लिखी है या नहीं ... लेकिन यह होता है) - और फिर - आपको एक त्रुटि है, शायद इसे उस फ़ंक्शन से लॉग करें जिसे कहा जाता है
   " createMergeCommit", लेकिन इसे उस सटीक रेखा पर ट्रेस नहीं कर सकता जिस पर यह हुआ था।

क्षमा करें अगर किसी ने पहले से ही ऐसा कुछ पोस्ट किया है (बहुत सारे अच्छे विचार हैं: पी) इस वैकल्पिक वाक्यविन्यास के बारे में कैसे:

fail := func(err error) error {
  log.Print("unexpected error", err)
  return err
}

a, b, err := f1()          // normal
c, d := f2() -> throw      // calls throw(err)
e, f := f3() -> panic      // calls panic(err)
g, h := f4() -> t.Error    // calls t.Error(err)
i, j := f5() -> fail       // calls fail(err)

यानी, आपके पास फ़ंक्शन कॉल के दाईं ओर एक -> handler है जिसे कॉल किया जाता है यदि लौटाई गई गलती != nil. हैंडलर कोई भी फ़ंक्शन है जो एक त्रुटि को एक तर्क के रूप में स्वीकार करता है और वैकल्पिक रूप से एक त्रुटि देता है (यानी, func(error) या func(error) error )। यदि हैंडलर शून्य त्रुटि देता है तो फ़ंक्शन जारी रहता है अन्यथा त्रुटि वापस आ जाती है।

तो a := b() -> handler इसके बराबर है:

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

अब, एक शॉर्टकट के रूप में आप try बिल्टिन (या कीवर्ड या ?= ऑपरेटर या जो कुछ भी) का समर्थन कर सकते हैं जो a := b() -> throw के लिए छोटा है ताकि आप कुछ लिख सकें:

func() error {
  a, b := try(f1())
  c, d := try(f2())
  e, f := try(f3())
  ...
  return nil
}() -> panic // or throw/fail/whatever

व्यक्तिगत रूप से मुझे एक ?= ऑपरेटर को एक कोशिश कीवर्ड/बिलिन से पढ़ने में आसान लगता है:

func() error {
  a, b ?= f1()
  c, d ?= f2()
  e, f ?= f3()
  ...
  return nil
}() -> panic

नोट : यहां मैं एक बिल्टिन के लिए प्लेसहोल्डर के रूप में फेंक का उपयोग कर रहा हूं जो कॉलर को त्रुटि लौटाएगा।

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

जिस तरह से प्रयास को प्रस्ताव में परिभाषित किया गया है और यह भविष्य के विस्तार को कैसे प्रभावित कर सकता है, मैं उसे एक छोटी सी समस्या के रूप में देखना चाहता हूं।

कोशिश को एक फ़ंक्शन के रूप में परिभाषित किया गया है जिसमें तर्कों की एक चर संख्या होती है।

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

फ़ंक्शन कॉल के परिणाम को try पर पास करना जैसा कि try(f()) में होता है, गो में कई रिटर्न वैल्यू के काम करने के तरीके के कारण निहित रूप से काम करता है।

प्रस्ताव के मेरे पढ़ने से, निम्नलिखित स्निपेट मान्य और शब्दार्थ दोनों के बराबर हैं।

a, b = try(f())
//
u, v, err := f()
a, b = try(u, v, err)

प्रस्ताव अतिरिक्त तर्कों के साथ try के विस्तार की संभावना भी बढ़ाता है।

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

मान लीजिए कि हम एक हैंडलर तर्क जोड़ना चाहते हैं। यह या तो तर्क सूची की शुरुआत या अंत में जा सकता है।

var h handler
a, b = try(h, f())
// or
a, b = try(f(), h)

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

func f() (handler, error) { ... }
func g() (error) { ... }
try(f())
try(h, g())

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

इनमें से कोई भी समस्या शोस्टॉपर नहीं है, लेकिन वे try को बाकी भाषा के साथ असंगत महसूस कराते हैं, और इसलिए मुझे यकीन नहीं है कि भविष्य में try का विस्तार करना आसान होगा क्योंकि प्रस्ताव राज्यों।

@जादुई

एक हैंडलर होना शक्तिशाली है, शायद:
मैंने पहले ही घोषित कर दिया था कि,

आप ऐसा कर सकते हैं

var h handler
a, b, h = f()

या

a, b, h.err = f()

यदि यह एक फ़ंक्शन जैसा है:

h:= handler(err error){
 log(...)
 return ....
} 

तब आग्रह था

a, b, h(err) = f()

सभी हैंडलर का आह्वान कर सकते हैं
और आप हैंडलर को "चयन" भी कर सकते हैं जो कुछ सुझावों के अनुसार त्रुटि (conitnue/ब्रेक/रिटर्न) को लौटाता है या केवल कैप्चर करता है।

और इस प्रकार varargs मुद्दा चला गया है।

@brynbellomy के else सुझाव का एक विकल्प:

a, b := try f() else err { /* handle error */ }

अन्य के तुरंत बाद एक सजावट समारोह का समर्थन करने के लिए हो सकता है:

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

try a, b := f() else decorate
try c, d := g() else decorate

और शायद कुछ उपयोगिता भी कुछ इस तरह से काम करती है:

decorate := fmt.DecorateErrorf("foo failed")

डेकोरेशन फंक्शन में हस्ताक्षर func(error) error हो सकते हैं, और कोशिश किए जा रहे संबंधित फंक्शन से रिटर्न की कोशिश करने से ठीक पहले, एक त्रुटि की उपस्थिति में try द्वारा कॉल किया जा सकता है।

यह प्रस्ताव दस्तावेज़ से पहले के "डिज़ाइन पुनरावृत्तियों" में से एक की भावना के समान होगा:

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

अगर कोई कुछ अधिक जटिल या बयानों का एक ब्लॉक चाहता है, तो वे इसके बजाय if (जैसे वे आज कर सकते हैं) का उपयोग कर सकते हैं।

उस ने कहा, https://github.com/golang/go/issues/32437#issuecomment -500949780 में @brynbellomy के उदाहरण में दिखाए गए try के दृश्य संरेखण के बारे में कुछ अच्छा है।

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

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

यहाँ @brynbellomy के उदाहरण को try फ़ंक्शन के साथ फिर से लिखा गया है, जिसमें अच्छे संरेखण को बनाए रखने के लिए var ब्लॉक का उपयोग किया गया है जिसे @thepudds ने https://github.com/golang/go/issues में बताया है।

package main

import (
    "fmt"
    "time"
)

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    var (
        headRef          = try(r.Head())
        parentObjOne     = try(headRef.Peel(git.ObjectCommit))
        parentObjTwo     = try(remoteBranch.Reference.Peel(git.ObjectCommit))
        parentCommitOne  = try(parentObjOne.AsCommit())
        parentCommitTwo  = try(parentObjTwo.AsCommit())
        treeOid          = try(index.WriteTree())
        tree             = try(r.LookupTree(treeOid))
        remoteBranchName = try(remoteBranch.Name())
    )

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return err
}

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

हालांकि, यह सवाल उठाता है कि try var ब्लॉक में कैसे काम करता है। मुझे लगता है कि var की प्रत्येक पंक्ति को एक अलग कथन के रूप में गिना जाता है, न कि पूरे ब्लॉक को एक ही कथन के रूप में, जहां तक ​​​​कि जब असाइन किया जाता है उसका क्रम।

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

@thepudds

कोशिश ए, बी: = एफ () और सजाने के लिए

शायद यह मेरे मस्तिष्क की कोशिकाओं में बहुत गहरी जलन है, लेकिन यह मुझे बहुत ज्यादा प्रभावित करता है जैसे a

try a, b := f() ;catch(decorate)

और एक फिसलन ढलान a

a, b := f()
catch(decorate)

मुझे लगता है कि आप देख सकते हैं कि वह कहाँ जा रहा है, और मेरे लिए तुलना कर रहा है

    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()

साथ

    try ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    )

(या अंत में एक कैच भी)
दूसरा अधिक पठनीय है, लेकिन इस तथ्य पर जोर देता है कि नीचे दिए गए फ़ंक्शन 2 वर्र्स लौटाते हैं, और हम जादुई रूप से एक को त्याग देते हैं, इसे "जादू रिटर्न गलती" में एकत्रित करते हैं।

    try(err) ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    ); err!=nil {
      //handle the err
    }

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

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

if f() { return nil, err }

कृपया नहीं। यदि हम एक पंक्ति if चाहते हैं तो कृपया एक पंक्ति if बनाएं, उदाहरण के लिए:

if f() then return nil, err

लेकिन कृपया, कृपया लाइन ब्रेक को हटाकर सिंटैक्स सलाद को गले न लगाएं जिससे ब्रेसिज़ का उपयोग करने वाले कोड को पढ़ना आसान हो जाता है।

मैं कुछ बातों पर जोर देना चाहता हूं जो चर्चा की गर्मी में भूल गए होंगे:

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

2) वर्तमान प्रस्ताव के बारे में शिकायतों में से एक यह है कि इसे प्राप्त करने के लिए त्रुटि परिणाम को नाम देने की आवश्यकता है। किसी भी वैकल्पिक प्रस्ताव में एक ही समस्या होगी जब तक कि विकल्प अतिरिक्त सिंटैक्स, यानी, अधिक बॉयलरप्लेट (जैसे ... else err { ... } और इसी तरह) को स्पष्ट रूप से उस चर का नाम देने के लिए पेश नहीं करता है। लेकिन क्या दिलचस्प है: अगर हम किसी त्रुटि को सजाने के बारे में परवाह नहीं करते हैं और परिणाम पैरामीटर का नाम नहीं देते हैं, लेकिन फिर भी एक स्पष्ट return की आवश्यकता होती है क्योंकि एक प्रकार का स्पष्ट हैंडलर है, वह return कथन सभी (आमतौर पर शून्य) परिणाम मानों की गणना करनी होगी क्योंकि इस मामले में नग्न वापसी की अनुमति नहीं है। विशेष रूप से यदि कोई फ़ंक्शन त्रुटि को सजाने में बहुत अधिक त्रुटि देता है, तो वे स्पष्ट रिटर्न ( return nil, err , आदि) बॉयलरप्लेट में जोड़ते हैं। वर्तमान प्रस्ताव, और कोई भी विकल्प जिसके लिए स्पष्ट return की आवश्यकता नहीं है, उससे दूर हो जाता है। दूसरी ओर, यदि कोई त्रुटि को सजाना चाहता है, तो वर्तमान प्रस्ताव _requires_ कि एक नाम त्रुटि परिणाम (और इसके साथ अन्य सभी परिणाम) त्रुटि मान तक पहुंच प्राप्त करने के लिए। इसका अच्छा साइड इफेक्ट है कि एक स्पष्ट हैंडलर में कोई नग्न रिटर्न का उपयोग कर सकता है और अन्य सभी परिणाम मानों को दोहराना नहीं पड़ता है। (मुझे पता है कि नग्न रिटर्न के बारे में कुछ मजबूत भावनाएं हैं, लेकिन वास्तविकता यह है कि जब हम केवल त्रुटि परिणाम की परवाह करते हैं, तो अन्य सभी (आमतौर पर शून्य) परिणाम मूल्यों की गणना करना एक वास्तविक उपद्रव है - यह कुछ भी नहीं जोड़ता है कोड की समझ)। दूसरे शब्दों में, त्रुटि परिणाम को नाम देना ताकि इसे सजाया जा सके, बॉयलरप्लेट को और कम करने में सक्षम बनाता है।

@magical इसे इंगित करने के लिए धन्यवाद। मैंने प्रस्ताव पोस्ट करने के कुछ ही समय बाद इसे देखा (लेकिन इसे आगे नहीं लाया ताकि भ्रम पैदा न हो)। आप सही हैं कि जैसा है, try को बढ़ाया नहीं जा सका। सौभाग्य से फिक्स काफी आसान है। (जैसा कि ऐसा होता है कि हमारे पहले के आंतरिक प्रस्तावों में यह समस्या नहीं थी - इसे तब पेश किया गया जब मैंने प्रकाशन के लिए हमारे अंतिम संस्करण को फिर से लिखा और मौजूदा पैरामीटर पासिंग नियमों से अधिक बारीकी से मिलान करने के लिए try को सरल बनाने की कोशिश की। यह एक अच्छा लग रहा था - लेकिन जैसा कि यह निकला, त्रुटिपूर्ण, और अधिकतर बेकार - try(a, b, c, handle) लिखने में सक्षम होने का लाभ।)

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

वैसे भी, मुद्दा यह है कि try वाक्य रचनात्मक रूप से केवल एक, या शायद दो अभिव्यक्तियों को स्वीकार करता है। (लेकिन try के शब्दार्थ का वर्णन करना थोड़ा कठिन है।) परिणाम वह कोड होगा जैसे:

a, b := try(u, v, err)

अब अनुमति नहीं दी जाएगी। लेकिन इस काम को पहले स्थान पर करने का कोई कारण नहीं है: ज्यादातर मामलों में (जब तक a और b को परिणाम नाम नहीं दिया जाता है) यह कोड - यदि किसी कारण से महत्वपूर्ण है - आसानी से फिर से लिखा जा सकता है

a, b := u, v  // we don't care if the assignment happens in case of an error
try(err)

(या आवश्यकतानुसार if कथन का उपयोग करें)। लेकिन फिर, यह महत्वहीन लगता है।

उस रिटर्न स्टेटमेंट को सभी (आमतौर पर शून्य) परिणाम मानों की गणना करनी होगी क्योंकि इस मामले में नग्न रिटर्न की अनुमति नहीं है

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

@griesemer स्पष्टीकरण के लिए धन्यवाद। मैं भी इसी निष्कर्ष पर पहुंचा हूं।

एक बयान के रूप में try पर एक संक्षिप्त टिप्पणी: जैसा कि मुझे लगता है कि https://github.com/golang/go/issues/32437#issuecomment -501035322, try में उदाहरण में देखा जा सकता है। try कथनों की एक श्रृंखला बन जाता है, जो यह अस्पष्ट करता है कि कोड वास्तव में क्या कर रहा है।

मौजूदा कोड if err != nil ब्लॉक के बाद एक नए घोषित त्रुटि चर का पुन: उपयोग कर सकता है। वेरिएबल को छिपाने से वह टूट जाएगा, और फ़ंक्शन सिग्नेचर में एक नामांकित रिटर्न वेरिएबल जोड़ना हमेशा इसे ठीक नहीं करेगा।

हो सकता है कि त्रुटि घोषणा/असाइनमेंट को वैसे ही छोड़ना सबसे अच्छा हो, और stmt को संभालने वाली एक-पंक्ति त्रुटि ढूंढें।

err := f() // followed by one of

on err, return err            // any type can be tested for non-zero
on err, return fmt.Errorf(...)
on err, fmt.Println(err)      // doesn't stop the function
on err, hname err             // handler invocation without parens
on err, ignore err            // optional ignore handler logs error if defined

if err, return err            // alternatively, use if

handle hname(err error, clr caller) { // type caller has results of runtime.Caller()
   if err == io.Bad { return err }
   fmt.Println(clr.name, err)
}

एक try उप-अभिव्यक्ति घबरा सकती है, जिसका अर्थ है कि त्रुटि कभी अपेक्षित नहीं है। इसका एक प्रकार किसी भी त्रुटि को अनदेखा कर सकता है।

f(try g()) // panic on error
f(try_ g()) // ignore any error

इस प्रस्ताव का पूरा बिंदु सामान्य त्रुटि प्रबंधन को पृष्ठभूमि में फीका बनाना है - त्रुटि प्रबंधन कोड पर हावी नहीं होना चाहिए। लेकिन अभी भी स्पष्ट होना चाहिए।

मुझे एक बयान के रूप में try को सूचीबद्ध करने वाली टिप्पणियों का विचार पसंद है। यह स्पष्ट है, अभी भी चमकना आसान है (क्योंकि यह निश्चित लंबाई का है), लेकिन _so_ चमकाना आसान नहीं है (क्योंकि यह हमेशा एक ही स्थान पर होता है) कि उन्हें एक भीड़-भाड़ वाली रेखा में छिपाया जा सकता है। इसे defer fmt.HandleErrorf(...) के साथ भी जोड़ा जा सकता है जैसा कि पहले उल्लेख किया गया है, हालांकि इसमें त्रुटियों को लपेटने के लिए नामित पैरामीटर का दुरुपयोग करने का नुकसान है (जो अभी भी मेरे लिए एक चालाक हैक की तरह लगता है। चालाक हैक खराब हैं।)

एक अभिव्यक्ति के रूप में मुझे try पसंद नहीं आने का एक कारण यह है कि या तो इसे चमकाना बहुत आसान है, या चमकाना इतना आसान नहीं है। निम्नलिखित दो उदाहरण लें:

एक अभिव्यक्ति के रूप में प्रयास करें

// Too hidden, it's in a crowded function with many symbols that complicate the function.

f, err := os.OpenFile(try(FileName()), os.O_APPEND|os.O_WRONLY, 0600)

// Not easy enough, the word "try" already increases horizontal complexity, and it
// being an expression only encourages more horizontal complexity.
// If this code weren't collapsed to multiple lines, it would be extremely
// hard to read and unclear as to what's executing when.

fullContents := try(io.CopyN(
    os.Stdout,
    try(net.Dial("tcp", "localhost:"+try(buf.ReadString("\n"))),
    try(strconv.Atoi(try(buf.ReadString("\n")))),
))

एक कथन के रूप में प्रयास करें

// easy to see while still not being too verbose

try name := FileName()
os.OpenFile(name, os.O_APPEND|os.O_WRONLY, 0600)

// does not allow for clever one-liners, code remains much more readable.
// also, the code reads in sequence from top-to-bottom.

try port := r.ReadString("\n")
try lengthStr := r.ReadString("\n")
try length := strconv.Atoi(lengthStr)

try con := net.Dial("tcp", "localhost:"+port)
try io.CopyN(os.Stdout, con, length)

टेकअवे

यह कोड निश्चित रूप से विकसित है, मैं मानता हूँ। लेकिन मुझे जो मिल रहा है, वह सामान्य तौर पर, try एक अभिव्यक्ति के रूप में अच्छी तरह से काम नहीं करता है:

1. भीड़-भाड़ वाले भावों के बीच जिन्हें अधिक त्रुटि जाँच की आवश्यकता नहीं है
2. अपेक्षाकृत सरल मल्टीलाइन स्टेटमेंट जिनमें बहुत अधिक त्रुटि जाँच की आवश्यकता होती है

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

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

fullContents := try(io.CopyN(os.Stdout, try(net.Dial("tcp", "localhost:"+try(r.ReadString("\n"))), try(strconv.Atoi(try(r.ReadString("\n"))))))

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

इस तरह के सख्त कोडिंग सम्मेलनों वाली भाषा के लिए, मुझे नहीं लगता कि इसे वास्तव में भी अनुमति दी जानी चाहिए।

गो में घृणित कोड लिखना संभव है। इसे भयानक रूप से प्रारूपित करना भी संभव है; इसके खिलाफ सिर्फ मजबूत मानदंड और उपकरण हैं। गो के पास भी है goto ।

कोड समीक्षाओं के दौरान, मैं कभी-कभी लोगों से उपयोगी मध्यवर्ती नामों के साथ जटिल अभिव्यक्तियों को कई कथनों में तोड़ने के लिए कहता हूं। मैं उसी कारण से गहराई से नेस्टेड try s के लिए कुछ ऐसा ही करूंगा।

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

गो में घृणित कोड लिखना संभव है। इसे भयानक रूप से प्रारूपित करना भी संभव है; इसके खिलाफ सिर्फ मजबूत मानदंड और उपकरण हैं। गो भी गोटो है।

कोड समीक्षाओं के दौरान, मैं कभी-कभी लोगों से उपयोगी मध्यवर्ती नामों के साथ जटिल अभिव्यक्तियों को कई कथनों में तोड़ने के लिए कहता हूं। मैं उसी कारण से गहराई से नेस्टेड प्रयासों के लिए कुछ ऐसा ही करूंगा।

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