syscall.Chdir(dir) || &PathError{"chdir", dir, e}

वहां से e कहां से आता है? टाइपो?

या आपका मतलब था:

func Chdir(dir string) (e error) {
    syscall.Chdir(dir) || &PathError{"chdir", dir, e}
    return nil
}

(अर्थात, क्या निहित त्रुटि != nil check पहले परिणाम पैरामीटर में त्रुटि प्रदान करती है, जिसे निहित वापसी से पहले इसे फिर से संशोधित करने के लिए नामित किया जा सकता है?)

आह, मेरा अपना उदाहरण गड़बड़ कर दिया। अब तय: e होना चाहिए err । प्रस्ताव err को फंक्शन कॉल के एरर वैल्यू को होल्ड करने के दायरे में रखता है जब असाइनमेंट स्टेटमेंट में नहीं होता है।

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

यह @davecheney के लिए https://github.com/pkg/errors लिखा था

इस कोड में क्या होता है:

if foo, err := thing.Nope() || &PathError{"chdir", dir, err}; err == nil || ignoreError {
}

(माफी क्षमा करें यदि यह || &PathError{"chdir", dir, e} भाग के साथ भी संभव नहीं है; मैं यह व्यक्त करने की कोशिश कर रहा हूं कि यह मौजूदा व्यवहार के भ्रमित ओवरराइड की तरह लगता है, और निहित रिटर्न हैं ... डरपोक?)

@ object88 मैं इस नए मामले को एक SimpleStmt में अनुमति नहीं देने के साथ ठीक होगा जैसा कि if और for और switch स्टेटमेंट में उपयोग किया गया है। यह शायद सबसे अच्छा होगा, हालांकि यह व्याकरण को थोड़ा जटिल करेगा।

लेकिन अगर हम ऐसा नहीं करते हैं, तो क्या होता है कि यदि thing.Nope() एक गैर-शून्य त्रुटि देता है, तो कॉलिंग फ़ंक्शन &PathError{"chdir", dir, err} साथ वापस आ जाता है (जहां err है कॉल द्वारा वैरिएबल सेट thing.Nope() )। यदि thing.Nope() एक nil त्रुटि देता है, तो हम निश्चित रूप से जानते हैं कि err == nil if कथन की स्थिति में सत्य है, और इसलिए का शरीर यदि कथन निष्पादित किया जाता है। ignoreError चर कभी नहीं पढ़ा जाता है। यहां मौजूदा व्यवहार की कोई अस्पष्टता या ओवरराइड नहीं है; यहां पेश किए गए || की हैंडलिंग केवल तभी स्वीकार की जाती है जब || बाद की अभिव्यक्ति एक बूलियन मान नहीं है, जिसका अर्थ है कि यह वर्तमान में संकलित नहीं होगा।

मैं इस बात से सहमत हूं कि निहित रिटर्न डरपोक हैं।

हाँ, मेरा उदाहरण बहुत खराब है। लेकिन किसी if , for , या switch अंदर ऑपरेशन की अनुमति नहीं देने से बहुत सारे संभावित भ्रम का समाधान हो जाएगा।

चूंकि विचार के लिए बार आम तौर पर कुछ ऐसा होता है जो भाषा में करना मुश्किल होता है, मैंने यह देखने का फैसला किया कि इस संस्करण को भाषा में एन्कोड करना कितना मुश्किल था। दूसरों की तुलना में ज्यादा कठिन नहीं: https://play.golang.org/p/9B3Sr7kj39

मैं वास्तव में इन सभी प्रस्तावों को एक प्रकार का मूल्य और वापसी तर्कों में एक स्थिति को विशेष बनाने के लिए नापसंद करता हूं। यह कुछ मायनों में वास्तव में बदतर है क्योंकि यह इस विशिष्ट संदर्भ में err एक विशेष नाम भी बनाता है।

हालांकि मैं निश्चित रूप से सहमत हूं कि लोग (मेरे सहित!) अतिरिक्त संदर्भ के बिना त्रुटियों को वापस करने से थके हुए होने चाहिए।

जब अन्य रिटर्न मान होते हैं, जैसे

if err != nil {
  return 0, nil, "", Struct{}, wrap(err)
}

यह निश्चित रूप से पढ़ने के लिए थकाऊ हो सकता है। मुझे कुछ हद तक https://github.com/golang/go/issues/19642#issuecomment -288559297 में return ..., err लिए @nigeltao का सुझाव पसंद आया

अगर मैं सही ढंग से समझूं, तो सिंटैक्स ट्री बनाने के लिए पार्सर को अंतर करने के लिए चर के प्रकारों को जानना होगा

boolean := BoolFunc() || BoolExpr

तथा

err := FuncReturningError() || Expr

यह अच्छा नहीं लग रहा है।

थोड़ा ही काफी है...

जब वापसी अभिव्यक्ति सूची में दो अयस्क अधिक तत्व होते हैं, तो यह कैसे काम करता है?

बीटीडब्ल्यू, मुझे इसके बजाय घबराहट चाहिए।

err := doSomeThing()
panicIf(err)

err = doAnotherThing()
panicIf(err)

@ianlancetaylor आपके प्रस्ताव के उदाहरण में err अभी भी स्पष्ट रूप से घोषित नहीं किया गया है, और 'जादुई' (भाषा पूर्वनिर्धारित) के रूप में खींचा गया है, है ना?

या ऐसा कुछ होगा

func Chdir(dir string) error {
    return (err := syscall.Chdir(dir)) || &PathError{"chdir", dir, err}
}

?

दूसरी ओर (चूंकि इसे पहले से ही "भाषा परिवर्तन" के रूप में चिह्नित किया गया है ...)
एक नए ऑपरेटर (!! या ??) का परिचय दें जो त्रुटि पर शॉर्टकट करता है! = nil (या कोई अशक्त?)

func DirCh(dir string) (string, error) {
    return dir, (err := syscall.Chdir(dir)) !! &PathError{"chdir", dir, err}
}

क्षमा करें यदि यह बहुत दूर है :)

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

हालांकि, प्रस्तावित सिंटैक्स "||" पढ़ने के लिए बहुत सहज नहीं है, खासकर जब से प्रतीक को आमतौर पर OR ऑपरेटर के रूप में जाना जाता है। इसके अलावा, आप उन कार्यों से कैसे निपटते हैं जो कई मान और त्रुटि लौटाते हैं?

मैं यहां कुछ विचार फेंक रहा हूं। आउटपुट के रूप में त्रुटि का उपयोग करने के बजाय, हम इनपुट के रूप में त्रुटि का उपयोग कैसे करते हैं? उदाहरण: https://play.golang.org/p/rtfoCIMGAb

सभी टिप्पणियों के लिए धन्यवाद।

@opennota अच्छा बिंदु। यह अभी भी काम कर सकता है लेकिन मैं मानता हूं कि पहलू अजीब है।

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

@mattn panicif इस प्रस्ताव के प्रमुख तत्वों में से एक को संबोधित नहीं करता है, जो अतिरिक्त संदर्भ के साथ एक त्रुटि वापस करने का एक आसान तरीका है। और, ज़ाहिर है, कोई भी आज आसानी से पर्याप्त panicif लिख सकता है।

@tandr हां, err को जादुई रूप से परिभाषित किया गया है, जो बहुत भयानक है। एक और संभावना यह होगी कि त्रुटि-अभिव्यक्ति को त्रुटि को संदर्भित करने के लिए error का उपयोग करने की अनुमति दी जाए, जो एक अलग तरीके से भयानक है।

@tandr हम एक अलग ऑपरेटर का उपयोग कर सकते हैं लेकिन मुझे कोई बड़ा फायदा नहीं दिख रहा है। ऐसा लगता है कि परिणाम और अधिक पठनीय नहीं है।

@henryas मुझे लगता है कि प्रस्ताव बताता है कि यह कई परिणामों को कैसे संभालता है।

@henryas उदाहरण के लिए धन्यवाद। उस तरह के दृष्टिकोण के बारे में मुझे जो चीज नापसंद है वह यह है कि यह कोड के सबसे प्रमुख पहलू को संभालने में त्रुटि करता है। मैं चाहता हूं कि त्रुटि प्रबंधन मौजूद और दृश्यमान हो, लेकिन मैं नहीं चाहता कि यह लाइन पर पहली चीज हो। यह आज सच है, if err != nil मुहावरे और त्रुटि प्रबंधन कोड के इंडेंटेशन के साथ, और यदि त्रुटि प्रबंधन के लिए कोई नई सुविधाएँ जोड़ी जाती हैं तो यह सही रहना चाहिए।

एक बार फिर धन्यवाद।

@ianlancetaylor मुझे नहीं पता कि आपने मेरे खेल के मैदान के लिंक की जाँच की है, लेकिन इसमें एक "घबराहट" थी जो आपको अतिरिक्त संदर्भ जोड़ने देती है।

मैं यहां कुछ हद तक सरलीकृत संस्करण पुन: पेश करूंगा:

func panicIf(err error, transforms ...func(error) error) {
  if err == nil {
    return
  }
  for _, transform := range transforms {
    err = transform(err)
  }
  panic(err)
}

संयोग से, मैंने गोफरकॉन में सिर्फ एक

func DirCh(dir string) (string, error) {
    dir := syscall.Chdir(dir)        =: err; if err != nil { return "", err }
}

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

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

मुझे वास्तव में यहां @billyh द्वारा प्रस्तावित वाक्य रचना पसंद है

func Chdir(dir string) error {
    e := syscall.Chdir(dir) catch: &PathError{"chdir", dir, e}
    return nil
}

या अधिक जटिल उदाहरण https://github.com/pkg/errors का उपयोग कर

func parse(input io.Reader) (*point, error) {
    var p point

    err := read(&p.Longitude) catch: nil, errors.Wrap(err, "Failed to read longitude")
    err = read(&p.Latitude) catch: nil, errors.Wrap(err, "Failed to read Latitude")
    err = read(&p.Distance) catch: nil, errors.Wrap(err, "Failed to read Distance")
    err = read(&p.ElevationGain) catch: nil, errors.Wrap(err, "Failed to read ElevationGain")
    err = read(&p.ElevationLoss) catch: nil, errors.Wrap(err, "Failed to read ElevationLoss")

    return &p, nil
}

एक सरल विचार, त्रुटि सजावट के समर्थन के साथ, लेकिन अधिक कठोर भाषा परिवर्तन की आवश्यकता है (जाहिर है कि go1.10 के लिए नहीं) एक नया check कीवर्ड का परिचय है।

इसके दो रूप होंगे: check A और check A, B ।

A और B को error । दूसरा रूप केवल त्रुटि-सजाने के दौरान उपयोग किया जाएगा; जिन लोगों को अपनी त्रुटियों को सजाने की आवश्यकता नहीं है या नहीं चाहते हैं, वे सरल रूप का उपयोग करेंगे।

पहला फॉर्म (चेक ए)

check A मूल्यांकन करता है A । अगर nil , तो यह कुछ नहीं करता है। यदि नहीं nil , तो check एक return {<zero>}*, A तरह कार्य करता है।

उदाहरण

• यदि कोई फ़ंक्शन केवल एक त्रुटि देता है, तो इसे check साथ इनलाइन उपयोग किया जा सकता है, इसलिए

err := UpdateDB()    // signature: func UpdateDb() error
if err != nil {
    return err
}

हो जाता है

check UpdateDB()

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

a, b, err := Foo()    // signature: func Foo() (string, string, error)
if err != nil {
    return "", "", err
}

// use a and b

हो जाता है

a, b, err := Foo()
check err

// use a and b

दूसरा फॉर्म (चेक ए, बी)

check A, B मूल्यांकन करता है A । अगर nil , तो यह कुछ नहीं करता है। यदि नहीं nil , तो check एक return {<zero>}*, B तरह कार्य करता है।

यह त्रुटि-सजाने की जरूरतों के लिए है। हम अभी भी A पर जांच करते हैं, लेकिन यह B है जिसका उपयोग अंतर्निहित return ।

उदाहरण

a, err := Bar()    // signature: func Bar() (string, error)
if err != nil {
    return "", &BarError{"Bar", err}
}

हो जाता है

a, err := Foo()
check err, &BarError{"Bar", err}

टिप्पणियाँ

यह एक संकलन त्रुटि है

• का उपयोग check चीजें हैं जो करने के लिए मूल्यांकन नहीं है पर बयान error
• एक फ़ंक्शन में check का उपयोग करें जिसमें वापसी मान { type }*, error

दो-एक्सपीआर फॉर्म check A, B शॉर्ट-सर्किट है। B का मूल्यांकन नहीं किया जाता है यदि A nil ।

व्यावहारिकता पर नोट्स

सजावटी त्रुटियों के लिए समर्थन है, लेकिन आप क्लंकीयर check A, B सिंटैक्स के लिए केवल तभी भुगतान करते हैं जब आपको वास्तव में त्रुटियों को सजाने की आवश्यकता होती है।

if err != nil { return nil, nil, err } बॉयलरप्लेट (जो बहुत आम है) के लिए check err उतना ही संक्षिप्त है जितना स्पष्टता का त्याग किए बिना हो सकता है (नीचे सिंटैक्स पर नोट देखें)।

वाक्य रचना पर नोट्स

मेरा तर्क है कि इस तरह का सिंटैक्स ( check .. , लाइन की शुरुआत में, return ) नियंत्रण प्रवाह व्यवधान को छुपाए बिना त्रुटि जांच बॉयलरप्लेट को खत्म करने का एक अच्छा तरीका है। निहित रिटर्न परिचय।

<do-stuff> || <handle-err> और <do-stuff> catch <handle-err> ऊपर, या किसी अन्य थ्रेड में प्रस्तावित a, b = foo()? जैसे विचारों का एक नकारात्मक पहलू यह है कि वे नियंत्रण प्रवाह संशोधन को इस तरह से छिपाते हैं जिससे प्रवाह कठिन हो जाता है का अनुसरण; पूर्व में || <handle-err> मशीनरी के साथ एक अन्यथा सादे-दिखने वाली रेखा के अंत में जोड़ा जो बीच में और कोड की एक सादे-दिखने वाली रेखा के अंत में हर जगह दिखाई दे सकता है, संभवतः कई बार।

एक check स्टेटमेंट हमेशा मौजूदा ब्लॉक में टॉप-लेवल होगा, जिसमें अन्य स्टेटमेंट्स की प्रमुखता होगी जो कंट्रोल फ्लो को संशोधित करते हैं (उदाहरण के लिए, एक शुरुआती return )।

@ALTree , मुझे समझ में नहीं आया कि आपका उदाहरण कैसा है:

a, b, err := Foo()
check err

मूल से तीन मूल्यवान रिटर्न प्राप्त करता है:

return "", "", err

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

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

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

@ बिलीह यह ऊपर बताया गया है, उस लाइन पर जो कहती है:

यदि शून्य नहीं है, तो चेक एक return {<zero>}*, A तरह कार्य करता है

check त्रुटि को छोड़कर (अंतिम स्थिति में) किसी भी वापसी मूल्य का शून्य मान लौटाएगा।

उन मामलों के बारे में जहां आप एक त्रुटि के साथ एक मान्य मान वापस करना चाहते हैं

फिर आप if err != nil { मुहावरे का प्रयोग करेंगे।

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

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

ऊपर मेरा जवाब देखें। आपके पास अभी भी if और भाषा द्वारा आपको अभी दी जाने वाली सभी चीज़ें होंगी।

लगभग कोई भी आधुनिक संपादक आरक्षित शब्द को उजागर करने वाला है

शायद। लेकिन अपारदर्शी सिंटैक्स का परिचय देना, जिसे पढ़ने योग्य होने के लिए सिंटैक्स हाइलाइटिंग की आवश्यकता होती है, आदर्श नहीं है।

इस विशेष बग को भाषा में डबल रिटर्न सुविधा शुरू करके ठीक किया जा सकता है।
इस मामले में फ़ंक्शन a() 123 देता है:

फंक ए () इंट {
बी()
वापसी 456
}
फंक बी () {
वापसी वापसी इंट(123)
}

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

func हैंडल (var * foo, त्रुटि त्रुटि) (var * foo, त्रुटि त्रुटि) {
अगर गलती!= शून्य {
वापसी वापसी शून्य, त्रुटि
}
वापसी संस्करण, शून्य
}

func क्लाइंट_कोड () (* क्लाइंट_ऑब्जेक्ट, त्रुटि) {
वर obj, गलती = संभाल (something_that_can_fail ())
// यह केवल तभी प्राप्त होता है जब कुछ विफल नहीं होता है
// अन्यथा क्लाइंट_कोड फ़ंक्शन स्टैक तक त्रुटि का प्रचार करेगा
जोर दें (गलती == शून्य)
}

यह लोगों को एक त्रुटि हैंडलर फ़ंक्शन लिखने की अनुमति देता है जो त्रुटियों को स्टैक तक फैला सकता है
ऐसे त्रुटि प्रबंधन कार्य मुख्य कोड से अलग हो सकते हैं

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

func Chdir(dir string) (err error) {
    syscall.Chdir(dir) || err
    return nil
}

@rodcorsi इस प्रस्ताव के तहत आपका उदाहरण बिना किसी पशु चिकित्सक चेतावनी के स्वीकार किया जाएगा। यह के बराबर होगा

if err := syscall.Chdir(dir); err != nil {
    return err
}

त्रुटि को संभालने के लिए संदर्भ के उपयोग का विस्तार करने के बारे में कैसे? उदाहरण के लिए, निम्नलिखित परिभाषा दी गई है:
type ErrorContext interface { HasError() bool SetError(msg string) Error() string }
अब त्रुटि-प्रवण कार्य में ...
func MyFunction(number int, ctx ErrorContext) int { if ctx.HasError() { return 0 } return number + 1 }
इंटरमीडिएट समारोह में...
func MyIntermediateFunction(ctx ErrorContext) int { if ctx.HasError() { return 0 } number := 0 number = MyFunction(number, ctx) number = MyFunction(number, ctx) number = MyFunction(number, ctx) return number }
और ऊपरी स्तर के समारोह में
func main() { ctx := context.New() no := MyIntermediateFunction(ctx) if ctx.HasError() { log.Fatalf("Error: %s", ctx.Error()) return } fmt.Printf("%d\n", no) }
इस दृष्टिकोण का उपयोग करने के कई फायदे हैं। सबसे पहले, यह पाठक को मुख्य निष्पादन पथ से विचलित नहीं करता है। मुख्य निष्पादन पथ से विचलन को इंगित करने के लिए न्यूनतम "अगर" कथन है।

दूसरा, यह त्रुटि छुपाता नहीं है। मेथड सिग्नेचर से यह स्पष्ट है कि यदि यह ErrorContext को स्वीकार करता है, तो फंक्शन में त्रुटियाँ हो सकती हैं। फ़ंक्शन के अंदर, यह सामान्य ब्रांचिंग स्टेटमेंट (जैसे "अगर") का उपयोग करता है जो दिखाता है कि सामान्य गो कोड का उपयोग करके त्रुटि को कैसे नियंत्रित किया जाता है।

तीसरा, त्रुटि स्वचालित रूप से इच्छुक पार्टी तक पहुंच जाती है, जो इस मामले में संदर्भ स्वामी है। क्या कोई अतिरिक्त त्रुटि संसाधन होना चाहिए, यह स्पष्ट रूप से दिखाया जाएगा। उदाहरण के लिए, आइए किसी भी मौजूदा त्रुटि को लपेटने के लिए मध्यवर्ती फ़ंक्शन में कुछ बदलाव करें:
func MyIntermediateFunction(ctx ErrorContext) int { if ctx.HasError() { return 0 } number := 0 number = MyFunction(number, ctx) number = MyFunction(number, ctx) number = MyFunction(number, ctx) if ctx.HasError() { ctx.SetError(fmt.Sprintf("wrap msg: %s", ctx.Error()) return } number *= 20 number = MyFunction(number, ctx) return number }
मूल रूप से, आप केवल आवश्यकतानुसार एरर-हैंडलिंग कोड लिखते हैं। आपको उन्हें मैन्युअल रूप से बबल अप करने की आवश्यकता नहीं है।

अंत में, आप फ़ंक्शन लेखक के रूप में कहते हैं कि क्या त्रुटि को संभाला जाना चाहिए। वर्तमान गो दृष्टिकोण का उपयोग करना, यह करना आसान है ...
````
// निम्नलिखित परिभाषा दी गई है
func MyFunction (संख्या int) त्रुटि

// फिर यह करें
MyFunction(8)//त्रुटि की जाँच के बिना
With the ErrorContext, you as the function owner can make the error checking optional with this:
func MyFunction (ctx ErrorContext) {
अगर ctx != nil && ctx.HasError() {
वापसी
}
//...
}
Or make it compulsory with this:
func MyFunction (ctx ErrorContext) {
अगर ctx.HasError () {// अगर सीटीएक्स शून्य है तो घबराएगा
वापसी
}
//...
}
If you make error handling compulsory and yet the user insists on ignoring error, they can still do that. However, they have to be very explicit about it (to prevent accidental ignore). For instance:
func अपरफंक्शन (ctx ErrorContext) {
अनदेखा किया गया: = संदर्भ। नया ()
MyFunction (अनदेखा) // इसे अनदेखा किया जाता है

 MyFunction(ctx) //this one is handled

}
````
यह दृष्टिकोण मौजूदा भाषा में कुछ भी नहीं बदलता है।

@ALTree अल्बर्टो, आपके check मिलाने के बारे में क्या और @ianlancetaylor ने क्या प्रस्तावित किया?

इसलिए

func F() (int, string, error) {
   i, s, err := OhNo()
   if err != nil {
      return i, s, &BadStuffHappened(err, "oopsie-daisy")
   }
   // all is good
   return i+1, s+" ok", nil
}

हो जाता है

func F() (int, string, error) {
   i, s, err := OhNo()
   check i, s, err || &BadStuffHappened(err, "oopsie-daisy")
   // all is good
   return i+1, s+" ok", nil
}

साथ ही, हम check को केवल त्रुटि प्रकारों से निपटने के लिए सीमित कर सकते हैं, इसलिए यदि आपको एकाधिक रिटर्न मानों की आवश्यकता है, तो उन्हें नाम और असाइन करने की आवश्यकता है, इसलिए यह किसी भी तरह "इन-प्लेस" असाइन करता है और सरल "रिटर्न" जैसा व्यवहार करता है

func F() (a int, s string, err error) {
   i, s, err = OhNo()
   check err |=  &BadStuffHappened(err, "oopsy-daisy")  // assigns in place and behaves like simple "return"
   // all is good
   return i+1, s+" ok", nil
}

यदि return एक दिन अभिव्यक्ति में स्वीकार्य हो जाएगा, तो check की आवश्यकता नहीं है, या एक मानक फ़ंक्शन बन जाता है

func check(e error) bool {
   return e != nil
}

func F() (a int, s string, err error) {
   i, s, err = OhNo()
   check(err) || return &BadStuffHappened(err, "oopsy-daisy")
   // all is good
   return i+1, s+" ok", nil
}

आखिरी समाधान पर्ल की तरह लगता है हालांकि

मुझे याद नहीं है कि मूल रूप से इसे किसने प्रस्तावित किया था, लेकिन यहां एक और वाक्यविन्यास विचार है (हर किसी का पसंदीदा बाइकेड :-)। मैं यह नहीं कह रहा कि यह अच्छा है, लेकिन अगर हम विचारों को बर्तन में फेंक रहे हैं ...

x, y := try foo()

के बराबर होगा:

x, y, err := foo()
if err != nil {
    return (an appropriate number of zero values), err
}

तथा

x, y := try foo() catch &FooErr{E:$, S:"bad"}

के बराबर होगा:

x, y, err := foo()
if err != nil {
    return (an appropriate number of zero values), &FooErr{E:err, S:"bad"}
}

try फॉर्म निश्चित रूप से पहले, कई बार, मोडुलो सतही वाक्यविन्यास अंतरों से पहले प्रस्तावित किया गया है। try ... catch फ़ॉर्म अक्सर कम प्रस्तावित होता है, लेकिन यह स्पष्ट रूप से @ALTree के check A, B निर्माण और @tandr के अनुवर्ती सुझाव के समान है। एक अंतर यह है कि यह एक अभिव्यक्ति है, एक बयान नहीं, ताकि आप कह सकें:

z(try foo() catch &FooErr{E:$, S:"bad"})

आपके पास एक ही कथन में एकाधिक प्रयास/पकड़ हो सकते हैं:

p = try q(0) + try q(1)
a = try b(c, d() + try e(), f, try g() catch &GErr{E:$}, h()) catch $BErr{E:$}

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

जाहिर है, try और catch जैसे नए कीवर्ड गो 1.x संगतता को तोड़ देंगे।

मेरा सुझाव है कि हमें इस प्रस्ताव के लक्ष्य को निचोड़ लेना चाहिए। इस प्रस्ताव से कौन-सी समस्या का समाधान होगा? निम्नलिखित तीन पंक्तियों को दो या एक में कम करें? यह वापसी की भाषा का परिवर्तन हो सकता है/यदि।

if err != nil {
    return err
}

या गलती की जांच करने के लिए समय की संख्या कम करें? यह इसके लिए प्रयास/पकड़ समाधान हो सकता है।

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

1. यह उस कोड से पहले प्रकट नहीं होना चाहिए जिसकी वह जांच कर रहा है, ताकि गैर-त्रुटि पथ प्रमुख हो।
2. इसे दायरे में निहित चरों को पेश नहीं करना चाहिए, ताकि समान नाम के साथ एक स्पष्ट चर होने पर पाठक भ्रमित न हों।
3. इसे एक पुनर्प्राप्ति क्रिया (उदाहरण के लिए, return err ) को दूसरे की तुलना में आसान नहीं बनाना चाहिए। कभी-कभी एक पूरी तरह से अलग कार्रवाई बेहतर हो सकती है (जैसे t.Fatal कॉल करना)। हम लोगों को अतिरिक्त संदर्भ जोड़ने से हतोत्साहित नहीं करना चाहते हैं।

उन बाधाओं को देखते हुए, ऐसा लगता है कि लगभग एक न्यूनतम सिंटैक्स कुछ ऐसा होगा

STMT SEPARATOR_TOKEN VAR BLOCK

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

syscall.Chdir(dir) :: err { return err }

जो के बराबर है

if err := syscall.Chdir(dir); err != nil {
    return err
}
````
Even though it's not much shorter, the new syntax moves the error path out of the way. Part of the change would be to modify `gofmt` so it doesn't line-break one-line error-handling blocks, and it indents multi-line error-handling blocks past the opening `}`.

We could make it a bit shorter by declaring the error variable in place with a special marker, like

syscall.Chdir(dir) :: {वापसी @err }
```

मुझे आश्चर्य है कि यह गैर-शून्य-मान और त्रुटि दोनों के लिए कैसे व्यवहार करता है। उदाहरण के लिए, bufio.Peek संभवतः गैर-शून्य मान और ErrBufferFull दोनों को एक ही समय में लौटाता है।

@mattn आप अभी भी पुराने वाक्यविन्यास का उपयोग कर सकते हैं।

@nigeltao हाँ, मैं समझता हूँ। मुझे संदेह है कि यह व्यवहार संभवतः उपयोगकर्ता के कोड पर एक बग बना सकता है क्योंकि bufio.Peek भी गैर-शून्य और शून्य लौटाता है। कोड में निहित मान और त्रुटि दोनों नहीं होने चाहिए। तो मूल्य और त्रुटि दोनों को कॉलर (इस मामले में) को वापस कर दिया जाना चाहिए।

ret, err := doSomething() :: err { return err }
return ret, err

@jba आप जो वर्णन कर रहे हैं वह एक ट्रांसपोज़्ड फ़ंक्शन-कंपोज़िशन ऑपरेटर जैसा दिखता है:

syscall.Chdir(dir) ⫱ func (err error) { return &PathError{"chdir", dir, err} }

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

तो अब मैं तीन अवलोकनों के बारे में सोच रहा हूं जो सभी प्रकार से संबंधित हैं:

1. त्रुटि प्रबंधन फ़ंक्शन संरचना की तरह है, लेकिन जिस तरह से हम गो में काम करते हैं वह हास्केल के त्रुटि मोनैड के विपरीत है: क्योंकि हम अनुक्रमिक कोड के बजाय अधिकतर अनिवार्य लिख रहे हैं, हम त्रुटि को बदलना चाहते हैं (संदर्भ जोड़ने के लिए) बजाय गैर-त्रुटि मान (जिसे हम केवल एक चर से बांधना चाहते हैं)।

2. गो फ़ंक्शन जो (x, y, error) लौटाते हैं, आमतौर पर वास्तव में कुछ अधिक होता है जैसे संघ (#19412) (x, y) | error ।

3. उन भाषाओं में, जो यूनियनों को अनपैक या पैटर्न-मिलान करती हैं, मामले अलग-अलग स्कोप हैं, और गो में त्रुटियों के साथ हमें जो बहुत परेशानी होती है, वह अनपेक्षित रूप से पुनर्घोषित चर के छायांकन के कारण होती है जिसे उन स्कोप (# 21114) को अलग करके बेहतर बनाया जा सकता है।

तो शायद हम जो चाहते हैं वह वास्तव में =: ऑपरेटर जैसा है, लेकिन एक प्रकार के संघ-मिलान सशर्त के साथ:

syscall.Chdir(dir) =? err { return &PathError{"chdir", dir, err} }

```जाओ
n:= io.WriteString(w, s) =? गलती {वापसी गलती}

and perhaps a boolean version for `, ok` index expressions and type assertions:
```go
y := m[x] =! { return ErrNotFound }

दायरे को छोड़कर, यह केवल gofmt को एक-लाइनर्स के लिए अधिक अनुकूल होने के लिए बदलने से बहुत अलग नहीं है:

err := syscall.Chdir(dir); if err != nil { return &PathError{"chdir", dir, err} }

```जाओ
n, त्रुटि: = io.WriteString (w, s); अगर गलती! = शून्य {वापसी गलती}

```go
y, ok := m[x]; if !ok { return ErrNotFound }

लेकिन स्कोप बहुत बड़ी बात है! स्कोपिंग मुद्दे वे हैं जहां इस प्रकार का कोड "कुछ हद तक बदसूरत" से "सूक्ष्म बग" तक की रेखा को पार करता है।

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

syscall.Chdir(dir) or dump(err): errors.Wrap(err, "chdir failed")

syscall.Chdir(dir) or dump

साथ ही, मुझे समझ में नहीं आया कि असाइनमेंट के मामले में अंतिम तर्क पॉप किया गया है, उदाहरण के लिए:

resp := http.Get("https://example.com") or dump

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

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

यह अकेले इस प्रस्ताव को IMHO के लायक नहीं बनाता है।

व्यक्तिगत रूप से मैं इस वाक्यविन्यास को पसंद करता हूं

err := syscall.Chdir(dir)
if err != nil {
    return err
}
return nil

ऊपर

if err := syscall.Chdir(dir); err != nil {
    return err
}
return nil

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

@बीसीमिल्स :

स्कोपिंग को छोड़कर, यह केवल एक-लाइनर के लिए अधिक उत्तरदायी होने के लिए gofmt को बदलने से बहुत अलग नहीं है

सिर्फ गुंजाइश नहीं; बायां किनारा भी है। मुझे लगता है कि यह वास्तव में पठनीयता को प्रभावित करता है। मुझे लगता है

syscall.Chdir(dir) =: err; if err != nil { return &PathError{"chdir", dir, err} } 

की तुलना में बहुत स्पष्ट है

err := syscall.Chdir(dir); if err != nil { return &PathError{"chdir", dir, err} } 

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

विचार @bcmills को मिलाकर हम सशर्त पाइप अग्रेषण ऑपरेटर पेश कर सकते हैं।

F2 फ़ंक्शन निष्पादित किया जाएगा यदि अंतिम मान nil नहीं है ।

func F1() (foo, bar){}

first := F1() ?> last: F2(first, last)

रिटर्न स्टेटमेंट के साथ पाइप अग्रेषण का एक विशेष मामला

func Chdir(dir string) error {
    syscall.Chdir(dir) ?> err: return &PathError{"chdir", dir, err}
    return nil
}

एक अन्य अंक में @urandom द्वारा लाया गया वास्तविक उदाहरण
प्राथमिक प्रवाह में फोकस के साथ मेरे लिए और अधिक पठनीय

func configureCloudinit(icfg *instancecfg.InstanceConfig, cloudcfg cloudinit.CloudConfig) (cloudconfig.UserdataConfig, error) {
    // When bootstrapping, we only want to apt-get update/upgrade
    // and setup the SSH keys. The rest we leave to cloudinit/sshinit.
    udata := cloudconfig.NewUserdataConfig(icfg, cloudcfg) ?> err: return nil, err
    if icfg.Bootstrap != nil {
        udata.ConfigureBasic() ?> err: return nil, err
        return udata, nil
    }
    udata.Configure() ?> err: return nil, err
    return udata, nil
}

func ComposeUserData(icfg *instancecfg.InstanceConfig, cloudcfg cloudinit.CloudConfig, renderer renderers.ProviderRenderer) ([]byte, error) {
    if cloudcfg == nil {
        cloudcfg = cloudinit.New(icfg.Series) ?> err: return nil, errors.Trace(err)
    }
    _ = configureCloudinit(icfg, cloudcfg) ?> err: return nil, errors.Trace(err)
    operatingSystem := series.GetOSFromSeries(icfg.Series) ?> err: return nil, errors.Trace(err)
    udata := renderer.Render(cloudcfg, operatingSystem) ?> err: return nil, errors.Trace(err)
    logger.Tracef("Generated cloud init:\n%s", string(udata))
    return udata, nil
}

मैं सहमत हूं कि त्रुटि प्रबंधन एर्गोनोमिक नहीं है। अर्थात्, जब आप नीचे दिए गए कोड को पढ़ते हैं, तो आपको इसे if error not nil then पर मुखर करना होता है - जिसका अनुवाद if there is an error then ।

if err != nil {
    // handle error
}

मैं उपरोक्त कोड को इस तरह से व्यक्त करने की योग्यता रखना चाहता हूं-जो मेरी राय में अधिक पठनीय है।

if err {
    // handle error
}

बस मेरा विनम्र सुझाव :)

यह पर्ल जैसा दिखता है, इसमें जादू चर भी है
संदर्भ के लिए, पर्ल में आप करेंगे

खुला (फ़ाइल, $ फ़ाइल) या मर ("$ फ़ाइल नहीं खोल सकता: $!");

आईएमएचओ, यह इसके लायक नहीं है, एक बिंदु जो मुझे पसंद है वह है त्रुटि प्रबंधन
स्पष्ट है और 'आपके चेहरे में'

अगर हम इसके साथ चिपके रहते हैं, तो मैं चाहता हूं कि कोई जादू चर न हो, हमें होना चाहिए
त्रुटि चर का नाम देने में सक्षम

e:= syscall.Chdir(dir) ?> e: &PathError{"chdir", dir, e}

और हम || . से भिन्न प्रतीक का भी उपयोग कर सकते हैं इस कार्य के लिए विशिष्ट,
मुझे लगता है कि 'या' जैसे टेक्स्ट सिंबल पीछे की ओर होने के कारण संभव नहीं हैं
अनुकूलता

n, _, ग़लती, _ = somecall(...) ?> ग़लती: &PathError {"somecall", n, ग़लत}

मंगलवार, 1 अगस्त, 2017 को दोपहर 2:47 बजे, रोड्रिगो नोटिफिकेशन @github.com ने लिखा:

विचार को मिलाकर @bcmills https://github.com/bcmills हम पेश कर सकते हैं
सशर्त पाइप अग्रेषण ऑपरेटर।

F2 फ़ंक्शन निष्पादित किया जाएगा यदि अंतिम मान शून्य नहीं है ।

func F1 () (फू, बार) {}
प्रथम := F1() ?> अंतिम: F2 (प्रथम, अंतिम)

रिटर्न स्टेटमेंट के साथ पाइप अग्रेषण का एक विशेष मामला

func Chdir (डीआईआर स्ट्रिंग) त्रुटि {
syscall.Chdir(dir)?> त्रुटि: वापसी और पथ त्रुटि {"chdir", dir, त्रुटि}
वापसी शून्य
}

वास्तविक उदाहरण
https://github.com/juju/juju/blob/01b24551ecdf20921cf620b844ef6c2948fcc9f8/cloudconfig/providerinit/providerinit.go
एक अन्य अंक में @urandom https://github.com/urandom द्वारा लाया गया
प्राथमिक प्रवाह में फोकस के साथ मेरे लिए और अधिक पठनीय

func configCloudinit(icfg *instancecfg.InstanceConfig, Cloudcfg Cloudinit.CloudConfig) (cloudconfig.UserdataConfig, त्रुटि) {
// बूटस्ट्रैपिंग करते समय, हम केवल उपयुक्त-अपडेट/अपग्रेड प्राप्त करना चाहते हैं
// और SSH कुंजियों को सेटअप करें। बाकी हम Cloudinit/sshinit पर छोड़ देते हैं।
udata := cloudconfig.NewUserdataConfig(icfg, cloudcfg) ?> इरेट: रिटर्न nil, इरेट
अगर icfg.बूटस्ट्रैप != nil {
udata.ConfigureBasic() ?> err: रिटर्न nil, err
वापसी उडता, शून्य
}
udata.Configure() ?> इरेट: रिटर्न nil, इरेट
वापसी उडता, शून्य
}
func ComposeUserData(icfg *instancecfg.InstanceConfig, Cloudcfg Cloudinit.CloudConfig, रेंडरर रेंडरर्स.प्रोवाइडररेंडरर) ([]बाइट, एरर) {
अगर क्लाउडसीएफजी == शून्य {
Cloudcfg = Cloudinit.New(icfg.Series)?> एरर: रिटर्न nil, एरर्स। ट्रेस (इरेट)
}
configCloudinit(icfg, cloudcfg)?> त्रुटि: वापसी शून्य, त्रुटियाँ। ट्रेस (गलती)
ऑपरेटिंग सिस्टम := Series.GetOSFromSeries(icfg.Series) ?> एरर: रिटर्न nil, एरर्स। ट्रेस (इरेट)
udata := renderer.Render(cloudcfg, ऑपरेटिंग सिस्टम) ?> एरर: रिटर्न nil, एरर्स। ट्रेस (इरेट)
logger.Tracef("जेनरेटेड क्लाउड इनिट:\n%s", string(udata))
वापसी उडता, शून्य
}

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/21161#issuecomment-319359614 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AbwRO_J0h2dQHqfysf2roA866vFN4_1Jks5sTx5hgaJpZM4Oi1c-
.

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

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

@rodcorsi मुझे पता है कि यह मामूली लगता है, लेकिन मुझे लगता है कि दूसरे भाग के लिए ब्लॉक होना महत्वपूर्ण है: मौजूदा if और for स्टेटमेंट दोनों ब्लॉक का उपयोग करते हैं, और select और switch दोनों कर्ली-ब्रेस-सीमांकित सिंटैक्स का उपयोग करते हैं, इसलिए इस एक विशेष नियंत्रण-प्रवाह ऑपरेशन के लिए ब्रेसिज़ को छोड़ना अजीब लगता है।

यह सुनिश्चित करना भी बहुत आसान है कि पार्स ट्री स्पष्ट है यदि आपको नए प्रतीकों के बाद मनमानी अभिव्यक्तियों के बारे में चिंता करने की आवश्यकता नहीं है।

मेरे स्केच के लिए मेरे मन में सिंटैक्स और शब्दार्थ हैं:

NonZeroGuardStmt = ( Expression | IdentifierList ":=" Expression |
                     ExpressionList assign_op Expression ) "=?" [ identifier ] Block .
ZeroGuardStmt = ( Expression | IdentifierList ":=" Expression |
                  ExpressionList assign_op Expression ) "=!" Block .

एक NonZeroGuardStmt Block NonZeroGuardStmt निष्पादित करता है यदि Expression का अंतिम मान इसके प्रकार के शून्य मान के बराबर नहीं है। यदि कोई identifier मौजूद है, तो वह Block भीतर उस मान के लिए बाध्य है। एक ZeroGuardStmt Block ZeroGuardStmt निष्पादित करता है यदि Expression का अंतिम मान इसके प्रकार के शून्य मान के बराबर है।

के लिए := फार्म, के अन्य (प्रमुख) मान Expression करने के लिए बाध्य कर रहे हैं IdentifierList एक के रूप में ShortVarDecl । पहचानकर्ताओं को युक्त दायरे में घोषित किया गया है, जिसका अर्थ है कि वे Block भीतर भी दिखाई दे रहे हैं।

assign_op फ़ॉर्म के लिए, प्रत्येक बाईं ओर का ऑपरेंड पता करने योग्य होना चाहिए, एक मैप इंडेक्स एक्सप्रेशन, या (केवल = असाइनमेंट के लिए) रिक्त पहचानकर्ता होना चाहिए। ऑपरेंड को कोष्ठक में रखा जा सकता है। दाईं ओर के अन्य (अग्रणी) मान Expression का मूल्यांकन Assignment रूप में किया जाता है। असाइनमेंट Block निष्पादन से पहले होता है और इस पर ध्यान दिए बिना कि Block फिर निष्पादित किया जाता है या नहीं।

मेरा मानना ​​​​है कि यहां प्रस्तावित व्याकरण गो 1 के साथ संगत है: ? एक मान्य पहचानकर्ता नहीं है और उस चरित्र का उपयोग करने वाले कोई मौजूदा गो ऑपरेटर नहीं हैं, और हालांकि ! एक वैध ऑपरेटर है, कोई नहीं है मौजूदा उत्पादन जिसमें इसके बाद { ।

@bcmills LGTM ,

मैंने सोचा होगा कि आप =? और =! प्रत्येक को अपने आप में एक टोकन बना देंगे, जो व्याकरण को तुच्छ रूप से संगत बना देगा।

मैंने सोचा होगा कि तुम बनाओगे =? और =! प्रत्येक अपने आप में एक टोकन है, जो व्याकरण को तुच्छ रूप से संगत बना देगा।

हम व्याकरण में ऐसा कर सकते हैं, लेकिन लेक्सर में नहीं: अनुक्रम "=!" मान्य गो 1 कोड (https://play.golang.org/p/pMTtUWgBN9) में दिखाई दे सकता है।

कर्ली-ब्रेस वह है जो मेरे प्रस्ताव में पार्स को स्पष्ट बनाता है: =! वर्तमान में केवल एक बूलियन वैरिएबल की घोषणा या असाइनमेंट में दिखाई दे सकता है, और घोषणाएं और असाइनमेंट वर्तमान में कर्ली-ब्रेस (https) से ठीक पहले प्रकट नहीं हो सकते हैं ://play.golang.org/p/ncJyg-GMuL) जब तक कि एक निहित अर्धविराम (https://play.golang.org/p/lhcqBhr7Te) द्वारा अलग न किया गया हो।

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

मुझे check प्रस्ताव पसंद है क्योंकि आप इसे संभालने के लिए बढ़ा भी सकते हैं

f, err := os.Open(myfile)
check err
defer check f.Close()

अन्य प्रस्ताव ऐसा नहीं लगता कि वे defer साथ भी मिल सकते हैं। check भी बहुत पढ़ने योग्य है, और यदि आप इसे नहीं जानते हैं तो Google के लिए सरल है। मुझे नहीं लगता कि इसे error प्रकार तक सीमित करने की आवश्यकता है। कुछ भी जो अंतिम स्थिति में वापसी पैरामीटर है उसका उपयोग कर सकता है। तो, एक पुनरावर्तक के पास check लिए Next() bool ।

मैंने एक बार ऐसा स्कैनर लिखा था जो दिखता है

func (s *Scanner) Next() bool {
    if s.Error != nil || s.pos >= s.RecordCount {
        return false
    }
    s.pos++

    var rt uint8
    if !s.read(&rt) {
        return false
    }
...

इसके बजाय वह आखिरी बिट check s.read(&rt) सकता है।

@carlmjohnson

अन्य प्रस्ताव ऐसा नहीं लगता कि वे defer साथ भी मिल सकते हैं।

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

defer f.Close() =? err { return err }

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

defer func() {
  err := f.Close()
  check err, fmt.Errorf(…, err) // But this func() doesn't return an error!
}()

अंतर:

defer f.Close() =? err { return fmt.Errorf(…, err) }

इनमें से कई प्रस्तावों का औचित्य बेहतर "एर्गोनॉमिक्स" है, लेकिन मैं वास्तव में यह नहीं देखता कि इनमें से कोई भी इसे बनाने के अलावा बेहतर कैसे है इसलिए टाइप करने के लिए थोड़ा कम है। ये कोड की रखरखाव को कैसे बढ़ाते हैं? रचनाशीलता? पठनीयता? नियंत्रण प्रवाह को समझने में आसानी?

@jimmyfrasche

ये कोड की रखरखाव को कैसे बढ़ाते हैं? रचनाशीलता? पठनीयता? नियंत्रण प्रवाह को समझने में आसानी?

जैसा कि मैंने पहले उल्लेख किया था, इनमें से किसी भी प्रस्ताव का मुख्य लाभ शायद असाइनमेंट के स्पष्ट दायरे और err चर से आने की आवश्यकता होगी: #19727, #20148, #5634, #21114, और शायद विभिन्न के लिए अन्य देखें। जिस तरह से लोगों को त्रुटि प्रबंधन के संबंध में स्कोपिंग मुद्दों का सामना करना पड़ रहा है।

@bcmills एक प्रेरणा प्रदान करने के लिए धन्यवाद और खेद है कि मैंने इसे आपकी पिछली पोस्ट में याद किया।

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

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

मुझे वह धागा नहीं मिल रहा है क्या किसी के पास लिंक है?

ऐसी बहुत सी चीजें हैं जो मुझे लगता है कि गो के बारे में सुधार किया जा सकता है लेकिन := के व्यवहार ने मुझे हमेशा एक गंभीर गलती के रूप में मारा। शायद := के व्यवहार पर दोबारा गौर करना मूल समस्या को हल करने का तरीका है या कम से कम अन्य चरम परिवर्तनों की आवश्यकता को कम करने का तरीका है?

@jimmyfrasche

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

हां। यह उन चीजों में से एक है जो मुझे =? या :: ऑपरेटर के बारे में पसंद है जिसे @jba और मैंने प्रस्तावित किया है: यह गैर-त्रुटियों के (एक सीमित रूप से सीमित सबसेट) तक अच्छी तरह से विस्तारित है।

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

नियंत्रण प्रवाह को समझने में आसानी?

मेरे और @bcmills के प्रस्तावों में, आपकी आंख बाईं ओर नीचे की ओर स्कैन कर सकती है और आसानी से गैर-त्रुटि नियंत्रण प्रवाह में ले सकती है।

@bcmills मुझे लगता है कि मैं # 19412 में कम से कम आधे शब्दों के लिए ज़िम्मेदार हूं, इसलिए आपको मुझे योग प्रकारों पर बेचने की आवश्यकता नहीं है;)

जब एक त्रुटि के साथ सामान वापस करने की बात आती है तो चार मामले होते हैं

1. बस एक त्रुटि (कुछ भी करने की आवश्यकता नहीं है, बस एक त्रुटि लौटाएं)
2. सामान और एक त्रुटि (आप इसे ठीक वैसे ही संभालेंगे जैसे आप अभी करेंगे)
3. एक बात या एक त्रुटि (आप योग प्रकार का उपयोग कर सकते हैं! :tada: )
4. दो या दो से अधिक चीजें या एक त्रुटि

यदि आप 4 हिट करते हैं तो चीजें मुश्किल हो जाती हैं। टुपल प्रकारों को पेश किए बिना (स्ट्रक्चर के लेबल किए गए उत्पाद प्रकारों के साथ जाने के लिए लेबल रहित उत्पाद प्रकार) यदि आप "यह या एक त्रुटि" मॉडल करने के लिए योग प्रकारों का उपयोग करना चाहते हैं तो आपको संरचना में सब कुछ बंडल करके समस्या को केस 3 में कम करना होगा।

टपल प्रकारों का परिचय सभी प्रकार की समस्याओं और संगतता मुद्दों और अजीब ओवरलैप्स का कारण होगा ( func() (int, string, error) एक स्पष्ट रूप से परिभाषित टपल है या एकाधिक रिटर्न मान एक अलग अवधारणा हैं? यदि यह एक स्पष्ट रूप से परिभाषित टपल है तो क्या इसका मतलब func() (n int, msg string, err error) एक अंतर्निहित रूप से परिभाषित संरचना है!? यदि यह एक संरचना है, तो मैं फ़ील्ड तक कैसे पहुंचूं यदि मैं एक ही पैकेज में नहीं हूं!)

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

@jba मैं नहीं देखता कि यह एक वांछनीय संपत्ति कैसे है। नियंत्रण प्रवाह को दो आयामी बनाने की अवधारणा के साथ सहजता की सामान्य कमी के अलावा, बोलने के लिए, मैं वास्तव में नहीं सोच सकता कि यह क्यों नहीं है, हालांकि। क्या आप मुझे इसका लाभ समझा सकते हैं?

टपल प्रकारों को पेश किए बिना […]

मैं इसके साथ ठीक हूं: मुझे लगता है कि हमारे पास और अधिक पठनीय कॉल साइटें होंगी (कोई और गलती से स्थानांतरित स्थितित्मक बाइंडिंग नहीं!), और # 12854 वर्तमान में स्ट्रक्चर रिटर्न से जुड़े बहुत से ओवरहेड को कम कर देगा।

बड़ी समस्या प्रवासन है: हम गो 1 के "मान और त्रुटि" मॉडल से गो 2 में संभावित "मान या त्रुटि" मॉडल तक कैसे पहुंचेंगे, विशेष रूप से दिए गए एपीआई जैसे io.Writer जो वास्तव में "मान" लौटाते हैं और त्रुटि"?

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

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

i := match strconv.Atoi(str) | err error { return err }

जहां match पारंपरिक एमएल-शैली पैटर्न मिलान ऑपरेशन होगा, लेकिन एक गैर-विस्तृत मिलान के मामले में मूल्य वापस कर दिया जाएगा ( interface{} यदि संघ के पास एक से अधिक बेजोड़ विकल्प हैं) एक गैर-विस्तृत मैच विफलता से घबराने के बजाय।

मैंने अभी-अभी https://github.com/mpvl/errd पर एक पैकेज की जाँच की है जो यहाँ चर्चा किए गए मुद्दों को प्रोग्रामेटिक रूप से संबोधित करता है (कोई भाषा परिवर्तन नहीं)। इस पैकेज का सबसे महत्वपूर्ण पहलू यह है कि यह न केवल त्रुटि प्रबंधन को छोटा करता है, बल्कि इसे सही तरीके से करना भी आसान बनाता है। मैं दस्तावेज़ों में उदाहरण देता हूं कि पारंपरिक मुहावरेदार त्रुटि प्रबंधन जितना लगता है उससे कहीं अधिक मुश्किल है, खासकर defer के साथ बातचीत में।

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

अभी कुछ और उदाहरणों पर काम चल रहा है, लेकिन यह पैकेज प्रयोग के लिए तैयार है।

@bcmills a मिलियन:+1: #12854 के लिए

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

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

गो चीनी या जादू पर बड़ा नहीं है और यह एक प्लस है।

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

अगर गो 2 को योग प्रकार मिलते हैं-जो मुझे स्पष्ट रूप से झटका देगा (अच्छे तरीके से!)-अगर कुछ भी हो, तो "नई शैली" में जाने के लिए बहुत धीमी क्रमिक प्रक्रिया होनी चाहिए और इस बीच यहां भी होगा त्रुटियों को संभालने के तरीके में अधिक विखंडन और भ्रम, इसलिए मैं इसे शुद्ध सकारात्मक नहीं देखता। (हालांकि मैं तुरंत तीन चैनलों के बजाय chan union { Msg1 T; Msg2 S; Err error } जैसे सामान के लिए इसका उपयोग करना शुरू कर दूंगा)।

अगर यह प्री-गो1 होता और गो टीम कह सकती थी कि "हम अगले छह महीने सब कुछ आगे बढ़ाने में बिताएंगे और जब यह सामान तोड़ देगा, तो बने रहें" यह एक बात होगी, लेकिन अभी हम मूल रूप से फंस गए हैं भले ही हमें योग प्रकार मिले।

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

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

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

@jimmyfrasche मुझे नहीं लगता कि मैं इसके लिए एक तर्क बना सकता हूं। आप मेरी बात देख सकते README में उदाहरण देख सकते हैं। लेकिन अगर दृश्य साक्ष्य आपके लिए सम्मोहक नहीं है, तो मैं कुछ नहीं कह सकता।

@jba ने बात देखी और README पढ़ा। अब मैं समझता हूं कि आप कोष्ठक/फुटनोट/एंडनोट/सिडेनोट चीज़ के साथ कहां से आ रहे हैं (और मैं सिडेनोट्स (और कोष्ठक) का प्रशंसक हूं)।

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

भाषा परिवर्तन वाक्य-विन्यास को कुछ अधिक सुगठित बनाता है। @bcmills का उल्लेख है कि इससे स्कोपिंग में सुधार होता है, लेकिन मैं वास्तव में यह नहीं देखता कि यह कैसे हो सकता है जब तक कि इसमें := से अलग स्कोपिंग नियम न हों, लेकिन ऐसा लगता है कि इससे अधिक भ्रम पैदा होगा।

@bcmills मुझे आपकी टिप्पणी समझ में नहीं आ रही है। आप स्पष्ट रूप से उन्हें अलग बता सकते हैं। पुराना तरीका इस तरह दिखता है:

err := foo()
if err != nil {
  return n, err  // n can be non-zero
}

नया तरीका दिखता है

check foo()

या

foo() || &FooError{err}

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

@ianlancetaylor की आवश्यकताओं में जोड़ने के लिए: त्रुटि संदेशों को सरल बनाना न केवल चीजों को छोटा करना चाहिए, बल्कि त्रुटि को सही तरीके से संभालना भी आसान होना चाहिए। कार्यों को स्थगित करने के लिए पैनिक और डाउनस्ट्रीम त्रुटियों को पार करना सही होना मुश्किल है।

उदाहरण के लिए, Google क्लाउड स्टोरेज फ़ाइल को लिखने पर विचार करें, जहाँ हम किसी भी त्रुटि पर फ़ाइल लिखना बंद करना चाहते हैं:

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
    client, err := storage.NewClient(ctx)
    if err != nil {
        return err
    }
    defer client.Close()

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    defer func() {
        if r := recover(); r != nil {
            w.CloseWithError(fmt.Errorf("panic: %v", r))
            panic(r)
        }
        if err != nil {
            _ = w.CloseWithError(err)
        } else {
            err = w.Close()
        }
    }
    _, err = io.Copy(w, r)
    return err
}

इस कोड की सूक्ष्मताओं में शामिल हैं:

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

पैकेज त्रुटि का उपयोग करते हुए, यह कोड इस तरह दिखता है:

func writeToGS(ctx context.Context, bucket, dst, src string, r io.Reader) error {
    return errd.Run(func(e *errd.E) {
        client, err := storage.NewClient(ctx)
        e.Must(err)
        e.Defer(client.Close, errd.Discard)

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        e.Defer(w.CloseWithError)

        _, err = io.Copy(w, r)
        e.Must(err)
    })
}

errd.Discard एक त्रुटि हैंडलर है। त्रुटि हैंडलर का उपयोग लपेटने, लॉग करने, जो भी त्रुटियां हैं, के लिए भी किया जा सकता है।

e.Must foo() || wrapError . के बराबर है

e.Defer अतिरिक्त है और टालमटोल करने वाली त्रुटियों से निपटता है।

जेनरिक का उपयोग करते हुए, कोड का यह टुकड़ा कुछ इस तरह दिख सकता है:

func writeToGS(ctx context.Context, bucket, dst, src string, r io.Reader) error {
    return errd.Run(func(e *errd.E) {
        client := e.Must(storage.NewClient(ctx))
        e.Defer(client.Close, errd.Discard)

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        e.Defer(w.CloseWithError)

        _ = e.Must(io.Copy(w, r))
    })
}

यदि हम डेफर के उपयोग के तरीकों पर मानकीकरण करते हैं, तो यह ऐसा भी दिख सकता है:

func writeToGS(ctx context.Context, bucket, dst, src string, r io.Reader) error {
    return errd.Run(func(e *errd.E) {
        client := e.DeferClose(e.Must(storage.NewClient(ctx)), errd.Discard)
       e.Must(io.Copy(e.DeferClose(client.Bucket(bucket).Object(dst).NewWriter(ctx)), r)
    })
}

जहां DeferClose या तो Close या CloseWithError को चुनता है। यह नहीं कहना बेहतर है, लेकिन सिर्फ संभावनाएं दिखा रहा है।

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

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

@ALTree त्रुटि बॉक्स के बाहर "परिष्कृत त्रुटि-वसूली" को संभालती है।

@jimmyfrasche : errd मोटे तौर पर वही करता है जो आपके खेल के मैदान का उदाहरण करता है, लेकिन त्रुटियों और घबराहट को दूर करने में भी बुनता है।

@jimmyfrasche : मैं मानता हूं कि अधिकांश प्रस्ताव कोड में पहले से हासिल की जा सकने वाली चीज़ों में बहुत कुछ नहीं जोड़ते हैं।

@romainmenke : सहमत हैं कि संक्षिप्तता पर बहुत अधिक ध्यान दिया जाता है। चीजों को सही ढंग से करना आसान बनाने के लिए अधिक फोकस होना चाहिए।

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

@bcmills : हालाँकि errd अपने आप में स्कोपिंग मुद्दों को ठीक नहीं करता है, यह पहले से घोषित त्रुटि चर और सभी के लिए डाउनस्ट्रीम त्रुटियों को पारित करने की आवश्यकता को समाप्त करता है, जिससे त्रुटि प्रबंधन, AFAICT के लिए समस्या को काफी कम कर देता है।

ऐसा लगता है कि गलती पूरी तरह से आतंक और वसूली पर निर्भर है। ऐसा लगता है कि यह एक महत्वपूर्ण प्रदर्शन दंड के साथ आता है। मुझे यकीन नहीं है कि यह इस वजह से एक समग्र समाधान है।

@urandom : हुड के तहत इसे अधिक महंगा, लेकिन एकल स्थगित के रूप में कार्यान्वित किया जाता है।
यदि मूल कोड:

• नो डिफर का उपयोग करता है: त्रुटि का उपयोग करने का दंड बड़ा है, लगभग 100ns*।
• मुहावरेदार विलंब का उपयोग करता है: चलने का समय या त्रुटि एक ही क्रम का है, हालांकि कुछ हद तक धीमा
• स्थगित करने के लिए उचित त्रुटि प्रबंधन का उपयोग करता है: चलने का समय लगभग बराबर है; यदि विलंब की संख्या> 1 . है, तो त्रुटि तेजी से हो सकती है

अन्य उपरिव्यय:

• Defer को पासिंग क्लोजर (w.Close) वर्तमान में DeferClose या DeferFunc API का उपयोग करने की तुलना में लगभग 25ns* ओवरहेड जोड़ता है (रिलीज़ v0.1.0 देखें)। @rsc के साथ चर्चा करने के बाद मैंने एपीआई को सरल रखने और बाद में अनुकूलन के बारे में चिंता करने के लिए इसे हटा दिया।
• हैंडलर ( e.Must(err, msg("oh noes!") ) के रूप में इनलाइन त्रुटि स्ट्रिंग को लपेटने की लागत गो 1.8 के साथ लगभग 30ns है। टिप (1.9) के साथ, हालांकि, अभी भी एक आवंटन, मैंने 2ns पर लागत देखी। बेशक पूर्व-घोषित त्रुटि संदेशों के लिए लागत अभी भी नगण्य है।

(*) मेरे 2016 मैकबुक प्रो पर चलने वाले सभी नंबर।

कुल मिलाकर, यदि आपका मूल कोड defer का उपयोग करता है तो लागत स्वीकार्य लगती है। यदि नहीं, तो ऑस्टिन आस्थगन की लागत को काफी कम करने पर काम कर रहा है, इसलिए समय के साथ लागत कम भी हो सकती है।

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

@jimmyfrasche :

तब एक $EDITOR प्लगइन भाषा परिवर्तन के बिना काम करेगा

हां, मैं बातचीत में यही तर्क देता हूं। यहाँ मैं यह तर्क दे रहा हूँ कि यदि हम कोई भाषा परिवर्तन करते हैं, तो वह "सिडेनोट" की अवधारणा के अनुरूप होना चाहिए।

@nigeltao

आप स्पष्ट रूप से उन्हें अलग बता सकते हैं। पुराना तरीका इस तरह दिखता है:

मैं घोषणा के बिंदु के बारे में बात कर रहा हूं, उपयोग के बिंदु के बारे में नहीं।

यहां चर्चा किए गए कुछ प्रस्ताव कॉल साइट पर दोनों के बीच अंतर नहीं करते हैं, लेकिन कुछ करते हैं। यदि हम "मान या त्रुटि" मानने वाले विकल्पों में से एक चुनते हैं - जैसे || , try … catch , या match - तो यह उपयोग करने के लिए एक संकलन-समय त्रुटि होनी चाहिए वह सिंटैक्स "मान और त्रुटि" फ़ंक्शन के साथ है, और यह परिभाषित करने के लिए फ़ंक्शन के कार्यान्वयनकर्ता पर निर्भर होना चाहिए कि यह कौन सा है।

घोषणा के समय, वर्तमान में "मान और त्रुटि" और "मान या त्रुटि" के बीच अंतर करने का कोई तरीका नहीं है:

func Atoi(string) (int, error)

तथा

func WriteString(Writer, String) (int, error)

समान रिटर्न प्रकार हैं, लेकिन विभिन्न त्रुटि शब्दार्थ हैं।

@mpvl मैं

यदि हम विथडिफॉल्ट () के परिणाम पर संचालन के लिए शीर्ष-स्तरीय funcs जैसे सामान्य सहायकों को अनदेखा करते हैं, और मानते हैं कि सादगी के लिए हम हमेशा संदर्भ का उपयोग करते हैं, और प्रदर्शन के लिए किए गए किसी भी निर्णय को अनदेखा करते हैं तो पूर्ण न्यूनतम नंगे एपीआई कम हो जाएगा संचालन के नीचे?

type Handler = func(ctx context.Context, panicing bool, err error) error
Run(context.Context, func(*E), defaults ...Handler) //egregious style but most minimal
type struct E {...}
func (*E) Must(err error, handlers ...Handler)
func (*E) Defer(func() error, handlers ...Handler)

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

@jimmyfrasche

@bcmills का उल्लेख है कि यह स्कोपिंग में सुधार करता है लेकिन मैं वास्तव में नहीं देखता कि यह कैसे हो सकता है

मुख्य सुधार err चर को दायरे से बाहर रखने में है। इससे बग से बचना होगा जैसे कि https://github.com/golang/go/issues/19727 से लिंक किए गए

    res, err := ctxhttp.Get(ctx, c.HTTPClient, dirURL)
    if err != nil {
        return Directory{}, err
    }
    defer res.Body.Close()
    c.addNonce(res.Header)
    if res.StatusCode != http.StatusOK {
        return Directory{}, responseError(res)
    }

    var v struct {
        …
    }
    if json.NewDecoder(res.Body).Decode(&v); err != nil {
        return Directory{}, err
    }

बग अंतिम if-statement में होता है: Decode से त्रुटि हटा दी जाती है, लेकिन यह स्पष्ट नहीं है क्योंकि पहले के चेक से err अभी भी दायरे में था। इसके विपरीत, :: या =? ऑपरेटर का उपयोग करते हुए, जो लिखा जाएगा:

    res := ctxhttp.Get(ctx, c.HTTPClient, dirURL) =? err { return Directory{}, err }
    defer res.Body.Close()
    c.addNonce(res.Header)
    (res.StatusCode == http.StatusOK) =! { return Directory{}, responseError(res) }

    var v struct {
        …
    }
    json.NewDecoder(res.Body).Decode(&v) =? err { return Directory{}, err }

यहां दो स्कोपिंग सुधार हैं जो मदद करते हैं:

1. पहला err (पहले Get कॉल से) केवल return ब्लॉक के दायरे में है, इसलिए इसे बाद की जांच में गलती से उपयोग नहीं किया जा सकता है।
2. चूंकि err से Decode को उसी कथन में घोषित किया गया है जिसमें इसे शून्यता के लिए चेक किया गया है, घोषणा और चेक के बीच कोई विषमता नहीं हो सकती है।

(1) अकेले संकलन समय पर त्रुटि को प्रकट करने के लिए पर्याप्त होता, लेकिन (2) स्पष्ट तरीके से गार्ड स्टेटमेंट का उपयोग करते समय बचना आसान बनाता है।

@bcmills स्पष्टीकरण के लिए धन्यवाद

तो, res := ctxhttp.Get(ctx, c.HTTPClient, dirURL) =? err { return Directory{}, err } में =? मैक्रो का विस्तार होता है

var res *http.Reponse
{
  var err error
  res, err = ctxhttp.Get(ctx, c.HTTPClient, dirURL)
  if err != nil {
    return Directory{}, err 
  }
}

अगर यह सही है तो मेरा मतलब यही था जब मैंने कहा था कि इसे := से अलग अर्थशास्त्र रखना होगा।

ऐसा लगता है कि यह अपने स्वयं के भ्रम पैदा करेगा जैसे:

func f() error {
  var err error
  g() =? err {
    if err != io.EOF {
      return err
    }
  }
  //one could expect that err could be io.EOF here but it will never be so
}

जब तक मैंने कुछ गलत नहीं समझा।

हाँ, यह सही विस्तार है। आप सही कह रहे हैं कि यह := से अलग है, और यह जानबूझकर किया गया है।

ऐसा लगता है कि यह अपने ही भ्रम का कारण बनेगा

यह सच है। यह मेरे लिए स्पष्ट नहीं है कि क्या यह व्यवहार में भ्रमित करने वाला होगा। यदि ऐसा है, तो हम घोषणा के लिए गार्ड स्टेटमेंट के ":" वेरिएंट प्रदान कर सकते हैं (और "=" वेरिएंट केवल असाइन करें)।

(और अब है कि के बनाने के लिए मुझे लगता है कि ऑपरेटरों की वर्तनी किया जाना चाहिए ? और ! के बजाय =? और =! ।)

res := ctxhttp.Get(ctx, c.HTTPClient, dirURL) ?: err { return Directory{}, err }

लेकिन

func f() error {
  var err error
  g() ?= err { (err == io.EOF) ! { return err } }
  // err may be io.EOF here.
}

@mpvl errd बारे में मेरी मुख्य चिंता हैंडलर इंटरफ़ेस के साथ है: ऐसा लगता है कि यह कॉलबैक की कार्यात्मक-शैली पाइपलाइनों को प्रोत्साहित करता है, लेकिन कॉलबैक/निरंतरता शैली कोड के साथ मेरा अनुभव (दोनों अनिवार्य भाषाओं जैसे गो और सी ++ और कार्यात्मक में) एमएल और हास्केल) जैसी भाषाओं है कि यह अक्सर बहुत कठिन बराबर अनुक्रमिक / अनिवार्य शैली है, जो भी जाओ मुहावरों के बाकी के साथ संरेखित करने के लिए होता है से पालन करने के लिए है।

क्या आप एपीआई के हिस्से के रूप में Handler -स्टाइल चेन की कल्पना करते हैं, या आपकी Handler किसी अन्य सिंटैक्स के लिए स्टैंड-इन है जिस पर आप विचार कर रहे हैं (जैसे कि Block पर काम करने वाली कोई चीज़ एस?)

@bcmills मैं अभी भी जादू की विशेषताओं के साथ बोर्ड पर नहीं हूं जो एक ही पंक्ति में दर्जनों अवधारणाओं को भाषा में पेश करता है और केवल एक चीज के साथ काम करता है, लेकिन मुझे अंततः पता चलता है कि वे x, err := f(); if err != nil { return err } लिखने के लिए थोड़े छोटे तरीके से अधिक क्यों हैं

@bcmills मैंने @mpvl के प्रेरक उदाहरण को फिर से लिखा, जिसमें नवीनतम =? प्रस्ताव का उपयोग करते हुए कुछ गंभीर त्रुटि प्रबंधन है, जो हमेशा एक नया त्रुटि चर घोषित नहीं करता है:

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
        client := storage.NewClient(ctx) =? err { return err }
        defer client.Close()

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)

        defer func() {
                if r := recover(); r != nil { // r is interface{} not error so we can't use it here
                        _ = w.CloseWithError(fmt.Errorf("panic: %v", r))
                        panic(r)
                }

                if err != nil { // could use =! here but I don't see how that simplifies anything
                        _ = w.CloseWithError(err)
                } else {
                        err = w.Close()
                }
        }()

        io.Copy(w, r) =? err { return err } // what about n? does this need to be prefixed by a '_ ='?
        return nil
}

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

@jimmyfrasche वह कोड अपवाद है, नियम नहीं। हमें सुविधाओं को लिखना आसान बनाने के लिए डिज़ाइन नहीं करना चाहिए।

साथ ही, मैं सवाल करता हूं कि recover भी होना चाहिए या नहीं। अगर w.Write या r.Read (या io.Copy !) घबरा रहा है, तो शायद इसे समाप्त करना सबसे अच्छा है।

बिना recover , वहाँ के लिए कोई वास्तविक आवश्यकता है defer , और समारोह के नीचे हो सकता है

_ = io.Copy(w, r) =? err { _ = w.CloseWithError(err); return err }
return w.Close()

@jimmyfrasche

// r is interface{} not error so we can't use it here

ध्यान दें कि मेरा विशिष्ट शब्दांकन ( https://github.com/golang/go/issues/21161#issuecomment-319434101 में) शून्य-मानों के बारे में है, विशेष रूप से त्रुटियां नहीं।

// what about n? does this need to be prefixed by a '_ ='?

ऐसा नहीं है, हालांकि मैं इसके बारे में और अधिक स्पष्ट हो सकता था।

मैं उस उदाहरण में विशेष रूप से @mpvl के recover उपयोग को पसंद नहीं करता: यह मुहावरेदार नियंत्रण प्रवाह पर आतंक के उपयोग को प्रोत्साहित करता है, जबकि अगर कुछ भी मुझे लगता है कि हमें बाहरी recover कॉल को समाप्त करना चाहिए ( जैसे fmt ) गो 2 में मानक पुस्तकालय से।

उस दृष्टिकोण के साथ, मैं उस कोड को इस प्रकार लिखूंगा:

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
        client := storage.NewClient(ctx) =? err { return err }
        defer client.Close()

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        io.Copy(w, r) =? err {
                w.CloseWithError(err)
                return err
        }
        return w.Close()
}

दूसरी ओर, आप सही हैं कि एक मुहावरेदार पुनर्प्राप्ति के साथ मुहावरेदार त्रुटि प्रबंधन का समर्थन करने के उद्देश्य से सुविधाओं को लागू करने का बहुत कम अवसर है। हालांकि, Close ऑपरेशन से रिकवरी को अलग करने से IMO कुछ हद तक क्लीनर कोड बन जाता है।

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
        client := storage.NewClient(ctx) =? err { return err }
        defer client.Close()

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        defer func() {
                if err != nil {
                        _ = w.CloseWithError(err)
                } else {
                        err = w.Close()
                }
        }()
        defer func() {
                recover() =? r {
                        err = fmt.Errorf("panic: %v", r)
                        panic(r)
                }
        }()

        io.Copy(w, r) =? err { return err }
        return nil
}

@jba डिफर हैंडलर री-

@bcmills कि अंतिम संशोधन बेहतर दिखता है (भले ही आपने =? निकाल लिया हो, वास्तव में)

@जेबीए :

_ = io.Copy(w, r) =? err { _ = w.CloseWithError(err); return err }
return w.Close()

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

वह कोड अपवाद है, नियम नहीं। हमें सुविधाओं को लिखना आसान बनाने के लिए डिज़ाइन नहीं करना चाहिए।

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

@jimmyfrasche : आपके सरलीकरण के संबंध में: आप लगभग सही हैं।

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

@mpvl मैं बस इसे कुछ चीजों तक

@jimmyfrasche : समझा, हालांकि यह अच्छा है अगर किसी एपीआई को आपको ऐसा करने की आवश्यकता नहीं है। :)

@bcmills : हैंडलर कुछ उद्देश्यों की पूर्ति करते हैं, उदाहरण के लिए, महत्व के क्रम में:

• एक त्रुटि लपेटें
• त्रुटियों को अनदेखा करने के लिए परिभाषित करें (इसे स्पष्ट करने के लिए। उदाहरण देखें)
• लॉग त्रुटियां
• त्रुटि मेट्रिक्स

फिर से महत्व के क्रम में, इन्हें इसके दायरे में लाने की आवश्यकता है:

• खंड मैथा
• रेखा
• पैकेज

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

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

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

@जेबीए :

साथ ही, मैं सवाल करता हूं कि क्या रिकवरी भी होनी चाहिए। यदि w.Write या r.Read (या io.Copy!) घबरा रहा है, तो शायद इसे समाप्त करना सबसे अच्छा है।

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

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

@बीसीमिल्स

मुझे उस उदाहरण में विशेष रूप से @mpvl का पुनर्प्राप्ति का उपयोग पसंद नहीं है: यह मुहावरेदार नियंत्रण प्रवाह पर आतंक के उपयोग को प्रोत्साहित करता है,

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

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

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

घोषणा के समय, वर्तमान में "मान और त्रुटि" और "मान या त्रुटि" के बीच अंतर करने का कोई तरीका नहीं है:

@bcmills ओह, मैं देखता हूँ। बाइकशेड का एक और कैन खोलने के लिए, मुझे लगता है कि आप कह सकते हैं

func Atoi(string) ?int

के बजाए

func Atoi(string) (int, error)

लेकिन WriteString अपरिवर्तित रहेगा:

func WriteString(Writer, String) (int, error)

मुझे समान प्रस्तावों की तुलना में @bcmills / @jba द्वारा =? / =! / :=? / :=! प्रस्ताव पसंद है। इसमें कुछ अच्छे गुण हैं:

• कंपोज़ेबल (आप =? उपयोग =? ब्लॉक में कर सकते हैं)
• सामान्य (केवल शून्य मान की परवाह करता है, त्रुटि प्रकार के लिए विशिष्ट नहीं)
• बेहतर गुंजाइश
• defer के साथ काम कर सकता है (उपरोक्त एक भिन्नता में)

इसमें कुछ गुण भी हैं जो मुझे उतने अच्छे नहीं लगते।

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

यह अपनी व्यापकता हासिल करने के लिए भाषा में मिथ्यात्व का परिचय देता है। मिथ्यात्व को "शून्य मान है (नहीं)" के रूप में परिभाषित किया जा रहा है, पूरी तरह से उचित है, लेकिन if err != nil { if err { से बेहतर है क्योंकि यह स्पष्ट है, मेरी राय में। मैं जंगली में गर्भपात देखने की उम्मीद करूंगा जो =? /etc का उपयोग करने का प्रयास करें। अपने मिथ्यात्व तक पहुँचने की कोशिश करने के लिए अधिक प्राकृतिक नियंत्रण प्रवाह पर। यह निश्चित रूप से एक मुहावरा होगा और उस पर तंज कसेगा, लेकिन ऐसा होगा। जबकि किसी विशेषता का संभावित दुरुपयोग अपने आप में किसी विशेषता के विरुद्ध तर्क नहीं है, यह विचार करने योग्य बात है।

कुछ मामलों में बेहतर स्कोपिंग (उनके पैरामीटर घोषित करने वाले वेरिएंट के लिए) अच्छा है, लेकिन अगर स्कोपिंग को ठीक करने की आवश्यकता है, तो सामान्य रूप से स्कोपिंग को ठीक करें।

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

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

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

कुछ पसंद करेंगे

func F() (S, T, error)

func MustF() (S, T) {
  return F() =? err { panic(err) }
}

अनुमति पाना?

अगर

defer f.Close() :=? err {
    return err
}

अनुमति है कि (किसी तरह) बराबर होना चाहिए

func theOuterFunc() (err error) {
  //...
  defer func() {
    if err2 := f.Close(); err2 != nil {
      err = err2
    }
  }()
  //...
}

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

वास्तव में हालांकि, थोड़ा बेहतर स्कोपिंग फिक्स के अलावा, यह गो में त्रुटियों से निपटने वाली किसी भी समस्या को ठीक नहीं करता है। अधिकांश टाइपिंग में if err != nil { return err } एक उपद्रव है, मैंने #21182 में व्यक्त की गई मामूली पठनीयता चिंताओं को संशोधित करें। दो सबसे बड़ी समस्याएं हैं

1. इस बारे में सोचना कि त्रुटि को कैसे संभालना है—और कोई भाषा इसके बारे में कुछ नहीं कर सकती
2. कुछ स्थितियों में क्या करना है, यह निर्धारित करने के लिए एक त्रुटि का आत्मनिरीक्षण करना— errors पैकेज के समर्थन के साथ कुछ अतिरिक्त सम्मेलन यहां बहुत आगे तक जाएंगे, हालांकि वे सभी समस्याओं का समाधान नहीं कर सकते हैं।

मुझे एहसास है कि केवल यही समस्याएं नहीं हैं और कई अन्य पहलुओं को अधिक तत्काल संबंधित पाते हैं, लेकिन वे वे हैं जिनके साथ मैं सबसे अधिक समय बिताता हूं और किसी भी चीज़ की तुलना में अधिक परेशान और परेशानी महसूस करता हूं।

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

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

@jimmyfrasche

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

मुझे वह धागा नहीं मिल रहा है क्या किसी के पास लिंक है?

मुझे लगता है कि आपको एक अलग धागा याद आ रहा होगा, जब तक कि आप गो में शामिल नहीं थे जब इसे जारी किया गया था। 2009/11/9 की कल्पना, रिलीज़ होने से ठीक पहले, में है:

नियमित चर घोषणाओं के विपरीत, एक लघु चर घोषणा चर को फिर से घोषित कर सकती है बशर्ते वे मूल रूप से एक ही प्रकार के एक ही ब्लॉक में घोषित किए गए हों, और कम से कम एक गैर-रिक्त चर नया हो।

मुझे याद है कि पहली बार कल्पना को पढ़ते समय और यह सोचकर कि यह एक महान नियम था, जैसा कि मैंने पहले := के साथ एक भाषा का उपयोग किया था, लेकिन उस पुन: उपयोग नियम के बिना, और उसी चीज़ के लिए नए नामों के बारे में सोचना थकाऊ था।

@mpvl
मुझे लगता है कि आपके मूल उदाहरण की चालबाजी का परिणाम अधिक है
गो की त्रुटि से निपटने के बजाय आप जिस एपीआई का उपयोग कर रहे हैं।

हालांकि यह एक दिलचस्प उदाहरण है, खासकर इस तथ्य के कारण कि
घबराहट होने पर आप फ़ाइल को सामान्य रूप से बंद नहीं करना चाहते हैं, इसलिए
सामान्य "defer w.Close ()" मुहावरा काम नहीं करता है।

यदि आपको कॉल करने से बचने की आवश्यकता नहीं है तो बंद करें जब कोई हो
घबराहट, तो आप कर सकते हैं:

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
    client, err := storage.NewClient(ctx)
    if err != nil {
        return err
    }
    defer client.Close()

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    defer w.Close()
    _, err = io.Copy(w, r)
    if err != nil {
        w.CloseWithError(err)
    }
    return err
}

यह मानते हुए कि शब्दार्थ को इस तरह बदल दिया गया था कि Close . को कॉल करना
CloseWithError को कॉल करने के बाद नो-ऑप है।

मुझे नहीं लगता कि अब यह इतना बुरा लगता है।

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

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    defer w.Close()
    _, err = io.Copy(w, r)
    return w.Finalize(err)

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

हालाँकि, मुझे लगता है कि इस उदाहरण का पैनिक-रिकवरी पहलू इस संदर्भ में कुछ हद तक रेड हेरिंग है, क्योंकि त्रुटि प्रबंधन के 99+% मामले पैनिक रिकवरी नहीं करते हैं।

@रोगपेप्पे :

हालांकि यह पैनिक एरर मैसेज को अटैच नहीं कर सकता है, लेकिन सभ्य लॉगिंग इसे स्पष्ट कर सकती है।

मुझे नहीं लगता कि यह कोई मुद्दा है।

आपका प्रस्तावित एपीआई परिवर्तन कम करता है लेकिन अभी तक पूरी तरह से समस्या का समाधान नहीं करता है। आवश्यक शब्दार्थ को ठीक से व्यवहार करने के लिए अन्य कोड की भी आवश्यकता होती है। नीचे दिए गए उदाहरण पर विचार करें:

r, w := io.Pipe()
go func() {
    var err error                // used to intercept downstream errors
    defer func() {
        w.CloseWithError(err)
    }()

    r, err := newReader()
    if err != nil {
        return
    }
    defer func() {
        if errC := r.Close(); errC != nil && err == nil {
            err = errC
        }
    }
    _, err = io.Copy(w, r)
}()
return r

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

पूर्णता के लिए, errd यह _would_ पैनिक को सही तरीके से हैंडल करेगा और ऐसा दिखेगा:

r, w := io.Pipe()
go errd.Run(func(e *errd.E) {
    e.Defer(w.CloseWithError)

    r, err := newReader()
    e.Must(err)
    e.Defer(r.Close)

    _, err = io.Copy(w, r)
    e.Must(err)
})
return r

यदि उपरोक्त पाठक ( errd का उपयोग नहीं कर रहा है) को लिखने के लिए पाठक के रूप में पारित किया गया है, और io.Reader newReader पैनिक्स द्वारा लौटाया गया है, तो यह अभी भी आपके प्रस्तावित एपीआई फिक्स के साथ दोषपूर्ण अर्थशास्त्र में परिणाम देगा (सफलतापूर्वक समापन में दौड़ सकता है शून्य त्रुटि के साथ घबराहट में पाइप बंद होने के बाद जीएस फ़ाइल।)

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

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

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

@mpvl
मैं अक्सर गो में त्रुटि प्रबंधन कोड के साथ पाता हूं कि एक और फ़ंक्शन बनाने से चीजें साफ हो सकती हैं। मैं आपका कोड कुछ इस तरह से लिखूंगा:

func something() {
    r, w := io.Pipe()
    go func() {
        err := copyFromNewReader(w)
        w.CloseWithError(err)
    }()
    ...
}

func copyFromNewReader(w io.Writer) error {
    r, err := newReader()
    if err != nil {
        return err
    }
    defer r.Close()
    _, err = io.Copy(w, r)
    return err
}()

मुझे लगता है कि r.Close एक उपयोगी त्रुटि नहीं लौटाता है - यदि आपने एक पाठक के माध्यम से सभी तरह से पढ़ा है और केवल io.EOF का सामना किया है, तो यह लगभग निश्चित रूप से कोई फर्क नहीं पड़ता कि यह बंद होने पर एक त्रुटि देता है।

मैं गलत एपीआई के लिए उत्सुक नहीं हूं - यह शुरू होने वाले गोरोइन्स के प्रति बहुत संवेदनशील है। उदाहरण के लिए: https://play.golang.org/p/iT441gO5us क्या कुछ करते हैं या चलाने के लिए एक गोरूटीन शुरू नहीं करते हैं
function in प्रोग्राम की शुद्धता को प्रभावित नहीं करना चाहिए, लेकिन errd का उपयोग करते समय, यह करता है। आप पैनिक से सुरक्षित रूप से अमूर्त सीमाओं को पार करने की उम्मीद कर रहे हैं, और वे गो में नहीं हैं।

@mpvl

स्थगित w.CloseWithError (गलती)

बीटीडब्लू, यह लाइन हमेशा CloseWithError को शून्य त्रुटि मान के साथ कॉल करती है। मुझे लगता है कि आपका मतलब था
लिखो:

defer func() { 
   w.CloseWithError(err)
}()

@mpvl

ध्यान दें कि Close विधि द्वारा io.Reader पर लौटाई गई त्रुटि लगभग कभी भी उपयोगी नहीं होती है (सूची देखें https://github.com/golang/go/issues/20803#issuecomment-312318808 )

इससे पता चलता है कि हमें आज आपका उदाहरण इस प्रकार लिखना चाहिए:

r, w := io.Pipe()
go func() (err error) {
    defer func() { w.CloseWithError(err) }()

    r, err := newReader()
    if err != nil {
        return err
    }
    defer r.Close()

    _, err = io.Copy(w, r)
    return err
}()
return r

... जो थोड़ा वर्बोज़ होने के अलावा, मुझे बिल्कुल ठीक लगता है।

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

-go func() (err error) {
-   defer func() { w.CloseWithError(err) }()
+go func() (rerr error) {
+   rerr = errors.New("goroutine exited by panic")
+   defer func() { w.CloseWithError(rerr) }()

@rogpeppe : वास्तव में, धन्यवाद। :)

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

आप पैनिक से सुरक्षित रूप से अमूर्त सीमाओं को पार करने की उम्मीद कर रहे हैं, और वे गो में नहीं हैं।

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

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

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

@jimmyfrasche

यह अपनी व्यापकता हासिल करने के लिए भाषा में मिथ्यात्व का परिचय देता है।

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

हम ऑपरेटर को केवल शून्य प्रकारों के साथ काम करने के लिए परिभाषित करके बाद वाले को संबोधित कर सकते हैं (और शायद परिणामस्वरूप =! , क्योंकि यह अधिकतर बेकार होगा)।

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

क्या [ MustF ] जैसी किसी चीज़ की अनुमति होगी?

हां।

अगर [ defer f.Close() :=? err { ] की अनुमति है जो (किसी तरह) बराबर होना चाहिए
[ defer func() { … }() ]।

जरूरी नहीं, नहीं। इसका अपना शब्दार्थ हो सकता है (अज्ञात फ़ंक्शन की तुलना में call/cc अधिक)। मैंने =? में defer का उपयोग करने के लिए एक विशिष्ट परिवर्तन का प्रस्ताव नहीं दिया है (इसे कम से कम व्याकरण में बदलाव की आवश्यकता होगी), इसलिए मुझे यकीन नहीं है कि ऐसी परिभाषा कितनी जटिल होगी .

दो सबसे बड़ी समस्याएं हैं […]

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

( @rogpeppe , @davecheney , @dsnet , @crawshaw , I, और कुछ अन्य

@bcmills : इस कोड में दो समस्याएं हैं 1) जैसा कि @rogpeppe ने उल्लेख किया है: CloseWithError को पास की गई त्रुटि हमेशा शून्य होती है, और 2) यह अभी भी पैनिक को हैंडल नहीं करती है, इसका मतलब है कि एपीआई स्पष्ट रूप से सफलता की रिपोर्ट करेगा जब कोई घबराहट होगी ( लौटा हुआ r एक io.EOF उत्सर्जित कर सकता है, भले ही सभी बाइट्स नहीं लिखे गए हों), भले ही 1 तय हो।

अन्यथा मैं सहमत हूं कि बंद द्वारा लौटाई गई त्रुटि को अक्सर अनदेखा किया जा सकता है। हमेशा नहीं, हालांकि (पहला उदाहरण देखें)।

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

@बीसीमिल्स :

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

क्या यह? उस गोरौटाइन के डिफर्स को अभी भी बुलाया जाता है। जहां तक ​​मैं समझता हूं, वे पूरा होने तक दौड़ेंगे। इस मामले में बंद एक io.EOF संकेत देगा।

उदाहरण के लिए, https://play.golang.org/p/5CFbsAe8zF देखें। गोरोइन के आतंक के बाद भी यह खुशी से "फू" को दूसरे गोरोइन में भेजता है जो तब भी इसे स्टडआउट को लिखने के लिए बनाता है।

इसी तरह, अन्य कोड को एक पैनिकिंग गोरौटाइन (जैसे आपके उदाहरण में एक) से एक गलत io.EOF प्राप्त हो सकता है, सफलता का निष्कर्ष निकाल सकता है, और घबराहट वाले गोरौटाइन के आतंक को फिर से शुरू करने से पहले खुशी से जीएस को एक फाइल सबमिट कर सकता है।

आप अगले तर्क हो सकते हैं: अच्छी तरह से छोटी गाड़ी कोड न लिखें, लेकिन:

• फिर इन बगों को रोकना आसान बनाएं, और
• ओओएम जैसे बाहरी कारकों के कारण घबराहट हो सकती है।

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

यह समाप्त होने पर io.EOF को सिग्नल करने के लिए अभी भी शून्य के साथ बंद होना चाहिए, ताकि यह काम न करे।

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

यह समाप्त होने पर io.EOF को सिग्नल करने के लिए अभी भी शून्य के साथ बंद होना चाहिए, ताकि यह काम न करे।

क्यों नहीं? अंत में return err rerr से nil ।

@bcmills : आह मैं देखता हूं कि अब आपका क्या मतलब है। हाँ, यह काम करना चाहिए। हालांकि, मैं लाइनों की संख्या के बारे में चिंतित नहीं हूं, बल्कि कोड की सूक्ष्मता के बारे में चिंतित हूं।

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

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

मुझे आशा है कि आप मुझे वैकल्पिक वाक्य रचना के साथ अपने प्रस्ताव को अपहृत करने में कोई आपत्ति नहीं करेंगे - लोग इस तरह के बारे में कैसा महसूस करते हैं:

return err if f, err := os.Open("..."); err != nil

@SirCmpwn जो

यह उचित है, लेकिन आपका प्रस्ताव मुझे असहज भी करता है - यह एक अपारदर्शी वाक्य-विन्यास (||) का परिचय देता है जो उस तरह से अलग व्यवहार करता है जिस तरह से उपयोगकर्ताओं को उम्मीद करने के लिए प्रशिक्षित किया गया है || व्यवहार के लिए। सुनिश्चित नहीं है कि सही समाधान क्या है, इस पर कुछ और विचार करेंगे।

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

समझा।

यह थोड़ा अधिक कट्टरपंथी है, लेकिन हो सकता है कि मैक्रो-चालित दृष्टिकोण बेहतर काम करे।

f = try!(os.Open("..."))

try! टुपल में अंतिम मूल्य खाएगा और इसे वापस कर देगा यदि शून्य नहीं है, और अन्यथा शेष ट्यूपल वापस कर दें।

मैं सुझाव देना चाहता हूं कि हमारा समस्या कथन है,

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

इस समस्या कथन का समाधान करने के लिए, मैं Go 2.x में त्रुटि प्रबंधन सुधारों के लिए इन लक्ष्यों का प्रस्ताव करता हूं:

1. बॉयलरप्लेट को संभालने में दोहराव वाली त्रुटि को कम करता है और कोड पथ के प्राथमिक इरादे पर ध्यान केंद्रित करता है।
2. उचित त्रुटि प्रबंधन को प्रोत्साहित करता है, जिसमें उन्हें आगे प्रचारित करते समय त्रुटियों को लपेटना शामिल है।
3. स्पष्टता और सरलता के गो डिजाइन सिद्धांतों का पालन करता है।
4. त्रुटि प्रबंधन स्थितियों की व्यापक संभव सीमा में लागू होता है।

इस प्रस्ताव का मूल्यांकन:

f.Close() =? err { return fmt.Errorf(…, err) }

उन लक्ष्यों के अनुसार, मैं यह निष्कर्ष निकालूंगा कि यह लक्ष्य # 1 पर अच्छी तरह से सफल होता है। मुझे यकीन नहीं है कि यह # 2 के साथ कैसे मदद करता है, लेकिन यह संदर्भ जोड़ने की संभावना को कम नहीं करता है (मेरे अपने प्रस्ताव ने इस कमजोरी को # 2 पर साझा किया)। यह वास्तव में #3 और #4 पर सफल नहीं होता, हालांकि:
1) जैसा कि अन्य ने कहा है, त्रुटि मान जाँच और असाइनमेंट अपारदर्शी और असामान्य है; तथा
2) =? सिंटैक्स भी असामान्य है। समान लेकिन भिन्न =! सिंटैक्स के साथ संयुक्त होने पर यह विशेष रूप से भ्रमित करने वाला है। लोगों को उनके अर्थों के अभ्यस्त होने में कुछ समय लगेगा; तथा
3) त्रुटि के साथ एक वैध मान लौटाना इतना सामान्य है कि किसी भी नए समाधान को भी उस मामले को संभालना चाहिए।

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

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

भले ही, जैसा कि @rsc ने अपने लेख Toward Go 2 में बताया है , न तो समस्या का विवरण, न ही लक्ष्य और न ही कोई सिंटैक्स प्रस्ताव अनुभव रिपोर्ट के बिना आगे बढ़ने की संभावना है जो प्रदर्शित करता है कि समस्या महत्वपूर्ण है। हो सकता है कि विभिन्न सिंटैक्स प्रस्तावों पर बहस करने के बजाय, हमें डेटा का समर्थन करने के लिए खुदाई शुरू करनी चाहिए?

भले ही, जैसा कि @rsc ने अपने लेख,

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

if $val, err := $operation($args); err != nil {
  return err
}

जब कोड से अधिक बॉयलरप्लेट होता है, तो समस्या स्वयं स्पष्ट इम्हो होती है।

@ बिलीह

मुझे लगता है कि प्रारूप: f.Close() =? err { return fmt.Errorf(…, err) } अत्यधिक क्रियात्मक और भ्रमित करने वाला है। मुझे व्यक्तिगत रूप से नहीं लगता कि त्रुटि भाग किसी ब्लॉक में होना चाहिए। अनिवार्य रूप से, यह इसे 1 के बजाय 3 पंक्तियों में फैलाएगा। इसके अलावा, बंद परिवर्तन में आपको इसे वापस करने से पहले एक त्रुटि को संशोधित करने के अलावा और अधिक करने की आवश्यकता है, कोई केवल वर्तमान if err != nil { ... } उपयोग कर सकता है

=? ऑपरेटर भी थोड़ा भ्रमित करने वाला है। यह तुरंत स्पष्ट नहीं है कि वहां क्या हो रहा है।

कुछ इस तरह के साथ:
file := os.Open("/some/file") or raise(err) errors.Wrap(err, "extra context")
या आशुलिपि:
file := os.Open("/some/file") or raise
और स्थगित:
defer f.Close() or raise(err2) errors.ReplaceIfNil(err, err2)
थोड़ा अधिक चिंताजनक है और शब्द का चुनाव प्रारंभिक भ्रम को कम कर सकता है (अर्थात लोग तुरंत raise को अन्य भाषाओं जैसे अजगर के समान कीवर्ड के साथ जोड़ सकते हैं, या केवल यह घटा सकते हैं कि त्रुटि/अंतिम-गैर- डिफ़ॉल्ट-मान कॉलर को स्टैक)।

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

संपादित करें:
अगर हम "जादू" को थोड़ा कम करना चाहते हैं, तो पिछले उदाहरण भी इस तरह दिख सकते हैं:
file, err := os.Open("/some/file") or raise errors.Wrap(err, "extra context")
file, err := os.Open("/some/file") or raise err
defer err2 := f.Close() or errors.ReplaceIfNil(err, err2)
मुझे व्यक्तिगत रूप से लगता है कि पिछले उदाहरण बेहतर हैं, क्योंकि वे पूर्ण त्रुटि प्रबंधन को दाईं ओर ले जाते हैं, बजाय इसे विभाजित करने के जैसा कि यहां है। हालांकि यह स्पष्ट हो सकता है।

मैं सुझाव देना चाहता हूं कि हमारा समस्या कथन है, ...

मैं समस्या कथन से सहमत नहीं हूँ। मैं एक विकल्प सुझाना चाहता हूं:

भाषा के दृष्टिकोण से त्रुटि प्रबंधन मौजूद नहीं है। गो केवल एक पूर्व-घोषित त्रुटि प्रकार प्रदान करता है और यहां तक ​​​​कि यह केवल सुविधा के लिए है क्योंकि यह वास्तव में कुछ भी नया सक्षम नहीं करता है। त्रुटियाँ केवल मान हैं । त्रुटि प्रबंधन केवल सामान्य उपयोगकर्ता कोड है। भाषा POV से इसमें कुछ खास नहीं है और इसमें कुछ खास नहीं होना चाहिए। त्रुटि प्रबंधन के साथ एकमात्र समस्या यह है कि कुछ लोगों का मानना ​​है कि इस मूल्यवान और सुंदर सादगी को किसी भी कीमत पर समाप्त किया जाना चाहिए।

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

त्रुटि प्रबंधन को अधिक सामान्य बनाने का एक तरीका यह है कि इसे संघ-प्रकार/योग-प्रकार और अलिखित के संदर्भ में सोचा जाए। स्विफ्ट और रस्ट दोनों का समाधान किसके साथ है? ! वाक्यविन्यास, हालांकि मुझे लगता है कि जंग थोड़ा अस्थिर रहा है।

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

स्विफ्ट से प्रेरित वाक्य रचना पर एक छुरा:

func Failable() (*Thingie | error) {
    ...
}

guard thingie, err := Failable() else { 
    return wrap(err, "Could not make thingie)
}
// err is not in scope here

आप इसे अन्य चीजों के लिए भी इस्तेमाल कर सकते हैं, जैसे:

guard val := myMap[key] else { val = "default" }

@bcmills और @jba द्वारा प्रस्तावित समाधान =? केवल त्रुटि के लिए नहीं है, अवधारणा गैर शून्य के लिए है। यह उदाहरण सामान्य रूप से काम करेगा।

func Foo()(Bar, Recover){}
bar := Foo() =? recover { log.Println("[Info] Recovered:", recover)}

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

bar := Foo() =? recover: log.Println("[Info] Recovered:", recover)

@ बिलीह

1. जैसा कि अन्य ने कहा है, त्रुटि मान जांच और असाइनमेंट अपारदर्शी और असामान्य है; तथा

कृपया अधिक ठोस बनें: "अपारदर्शी और असामान्य" बेहद व्यक्तिपरक हैं। क्या आप कोड के कुछ उदाहरण दे सकते हैं जहां आपको लगता है कि प्रस्ताव भ्रमित करने वाला होगा?

1. द =? वाक्य रचना भी असामान्य है। […]

आईएमओ यह एक विशेषता है। अगर कोई असामान्य ऑपरेटर देखता है, तो मुझे संदेह है कि वे कुछ ऐसा मानने के बजाय यह देखने के इच्छुक हैं कि यह क्या करता है जो सटीक हो सकता है या नहीं।

1. त्रुटि के साथ एक मान्य मान लौटाना इतना सामान्य है कि किसी भी नए समाधान को भी उस मामले को संभालना चाहिए।

ऐसा होता है?

प्रस्ताव को ध्यान से पढ़ें: =? Block मूल्यांकन करने से पहले असाइनमेंट करता है, इसलिए उस मामले के लिए भी इसका इस्तेमाल किया जा सकता है:

n := r.Read(buf) =? err {
  if err == io.EOF {
    […]
  }
  return err
}

और जैसा कि @nigeltao ने उल्लेख किया है, आप हमेशा मौजूदा 'n, err:= r.Read(buf)` पैटर्न का उपयोग कर सकते हैं। सामान्य मामले के लिए स्कोपिंग और बॉयलरप्लेट में मदद करने के लिए एक सुविधा जोड़ने का मतलब यह नहीं है कि हमें इसे असामान्य मामलों के लिए भी इस्तेमाल करना चाहिए।

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

इयान मूल पोस्ट में जुड़े कई मुद्दों (और उनके उदाहरण) देखें।
https://github.com/golang/go/wiki/ExperienceReports#error -handling भी देखें।

यदि आपको उन रिपोर्टों से विशिष्ट अंतर्दृष्टि प्राप्त हुई है, तो कृपया इसे साझा करें।

@urandom

मुझे व्यक्तिगत रूप से नहीं लगता कि त्रुटि भाग किसी ब्लॉक में होना चाहिए। अनिवार्य रूप से, यह इसे 1 के बजाय 3 पंक्तियों में फैलाएगा।

ब्लॉक का उद्देश्य दुगना है:

1. त्रुटि-उत्पादक अभिव्यक्ति और उसके हैंडलर के बीच एक स्पष्ट दृश्य और व्याकरणिक विराम प्रदान करने के लिए, और
2. त्रुटि प्रबंधन की एक विस्तृत श्रृंखला की अनुमति देने के लिए (मूल पोस्ट में @ianlancetaylor के बताए गए लक्ष्य के अनुसार)।

3 लाइनें बनाम 1 भाषा परिवर्तन भी नहीं है: यदि पंक्तियों की संख्या आपकी सबसे बड़ी चिंता है, तो हम इसे gofmt एक साधारण परिवर्तन के साथ संबोधित कर सकते हैं।

file, err := os.Open("/some/file") or raise errors.Wrap(err, "extra context")
file, err := os.Open("/some/file") or raise err

हमारे पास पहले से ही return और panic ; उनमें से शीर्ष पर raise जोड़ने से ऐसा लगता है कि यह बहुत कम लाभ के लिए किसी फ़ंक्शन से बाहर निकलने के कई तरीके जोड़ता है।

defer err2 := f.Close() or errors.ReplaceIfNil(err, err2)

errors.ReplaceIfNil(err, err2) को कुछ बहुत ही असामान्य पास-बाय-रेफरेंस सेमेन्टिक्स की आवश्यकता होगी।
आप इसके बजाय पॉइंटर द्वारा err पास कर सकते हैं, मुझे लगता है:

defer err2 := f.Close() or errors.ReplaceIfNil(&err, err2)

लेकिन यह अभी भी मुझे बहुत अजीब लगता है। क्या or टोकन एक अभिव्यक्ति, एक बयान, या कुछ और बनाता है? (एक और ठोस प्रस्ताव मदद करेगा।)

@carlmjohnson

आपके guard … else कथन का ठोस वाक्य-विन्यास और शब्दार्थ क्या होगा? मेरे लिए, यह बहुत कुछ =? या :: जैसा लगता है, जिसमें टोकन और चर पदों की अदला-बदली होती है। (फिर से, एक और ठोस प्रस्ताव मदद करेगा: आपके मन में वास्तविक वाक्यविन्यास और अर्थशास्त्र क्या हैं?)

@बीसीमिल्स
काल्पनिक ReplaceIfNil एक सरल होगा:

func ReplaceIfNil(original, replacement error) error {
   if original == nil {
       return replacement
   }
   return original
}

इसमें कुछ भी असामान्य नहीं है। शायद नाम...

or एक बाइनरी ऑपरेटर होगा, जहां बायां ऑपरेंड या तो एक IdentifierList, या एक PrimaryExpr होगा। पूर्व के मामले में, इसे सबसे सही पहचानकर्ता में घटा दिया गया है। यह तब दाएं हाथ के ऑपरेंड को निष्पादित करने की अनुमति देता है यदि बाएं एक डिफ़ॉल्ट मान नहीं है।

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

f, err := os.Open("/some/file") or return ..., errors.Wrap(err, "more context")

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

if f, err := os.Open("/some/file"); err != nil {
     return errors.Wrap(err, "more context")
}

• यदि उपरोक्त परिभाषित चर if दायरे से बाहर उपलब्ध कराए जाने थे।
  और इन त्रुटि प्रबंधन ब्लॉकों के दृश्य शोर के कारण, यह अभी भी ऐसे कुछ बयानों को पढ़ने के लिए कठिन बना देगा। और यह उन शिकायतों में से एक है जो लोगों को त्रुटि प्रबंधन पर चर्चा करते समय होती है।

@urandom

or एक बाइनरी ऑपरेटर होगा, जहां बायां ऑपरेंड या तो एक पहचानकर्ता सूची या एक PrimaryExpr होगा। [...] यह तब दाएं हाथ के ऑपरेंड को निष्पादित करने की अनुमति देता है यदि बायां एक डिफ़ॉल्ट मान नहीं है।

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

यह मानते हुए कि यह वास्तव में एक कथन है, दाएँ हाथ का संकार्य क्या है? यदि यह एक व्यंजक है, तो इसका प्रकार क्या है, और क्या raise को अन्य संदर्भों में व्यंजक के रूप में प्रयोग किया जा सकता है? यदि यह एक कथन है, तो इसके शब्दार्थ क्या हैं यदि raise अलावा कुछ भी हो? या आप or raise को अनिवार्य रूप से एक ही कथन के रूप में प्रस्तावित कर रहे हैं (उदाहरण के लिए or raise :: या =? सिंटैक्स विकल्प के रूप में)?

क्या मैं लिख सकता हूँ?

defer f.Close() or raise(err2) errors.ReplaceIfNil(err, err2) or raise(err3) Transform(err3)

?

क्या मैं लिख सकता हूँ?

f(r.Read(buf) or raise err)

?

defer f.Close() or raise(err2) errors.ReplaceIfNil(err, err2) or raise(err3) Transform(err3)

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

defer f.Close() or raise(err2) Transform(errors.ReplaceIfNil(err, err2)

f(r.Read(buf) or raise err)

अगर हम मेरी मूल टिप्पणी मान लें - बाईं ओर का अंतिम मान कहां या ले जाएगा, ताकि यदि यह एक डिफ़ॉल्ट मान था, तो अंतिम अभिव्यक्ति शेष परिणाम सूची का मूल्यांकन करेगी; तो हाँ, यह मान्य होना चाहिए। इस मामले में, यदि r.Read एक त्रुटि देता है, तो वह त्रुटि कॉलर को वापस कर दी जाती है। अन्यथा, n को f भेज दिया जाएगा

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

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

यह आदर्श स्थिति हो जाएगा, लेकिन मैं ठीक साथ भी कर रहा हूँ or raise करने के लिए सिर्फ एक वाक्य रचना वैकल्पिक जा रहा है =? के रूप में इसलिए, जब तक कि यह भी एक ब्लॉक के बजाय एक साधारण बयान स्वीकार करता है, उपयोग के अधिकांश मामलों को कम वर्बोज़ तरीके से कवर करें। या हम एक आस्थगित व्याकरण के साथ भी जा सकते हैं, जहां यह एक अभिव्यक्ति को स्वीकार करता है। इसमें अधिकांश मामलों को शामिल किया जाएगा जैसे:

f := os.Open("/some/file") or raise(err) errors.Wrap(err, "with context")

और जटिल मामले:

f := os.Open or raise(err) func() {
     if err == io.EOF {
         […]
     }
  return err
}()

अपने प्रस्ताव के बारे में थोड़ा और सोचते हुए, मैं संघ/सम-प्रकारों के बारे में थोड़ा सा छोड़ रहा हूं। मैं जिस वाक्य रचना का प्रस्ताव कर रहा हूं वह है

guard [ ASSIGNMENT || EXPRESSION ] else { [ BLOCK ] }

अभिव्यक्ति के मामले में, अभिव्यक्ति का मूल्यांकन किया जाता है और यदि परिणाम बूलियन अभिव्यक्तियों के लिए true बराबर नहीं है या अन्य अभिव्यक्तियों के लिए रिक्त मान है, तो ब्लॉक निष्पादित किया जाता है। एक असाइनमेंट में, अंतिम असाइन किए गए मान का मूल्यांकन != true / != nil । एक गार्ड स्टेटमेंट के बाद, किया गया कोई भी असाइनमेंट स्कोप में होगा (यह एक नया ब्लॉक स्कोप नहीं बनाता है [शायद आखिरी वेरिएबल को छोड़कर?])।

स्विफ्ट में, guard स्टेटमेंट के लिए ब्लॉक में return , break , continue , या throw । मैंने तय नहीं किया है कि मुझे यह पसंद है या नहीं। यह कुछ मूल्य जोड़ने लगता है क्योंकि एक पाठक guard शब्द से जानता है कि आगे क्या होगा।

क्या कोई स्विफ्ट का पालन यह कहने के लिए पर्याप्त रूप से करता है कि क्या guard उस समुदाय द्वारा अच्छी तरह से माना जाता है?

उदाहरण:

guard f, err := os.Open("/some/file") else { return errors.Wrap(err, "could not open:") }

guard data, err := ioutil.ReadAll(f) else { return errors.Wrap(err, "could not read:") }

var obj interface{}

guard err = json.Unmarshal(data, &obj) else { return errors.Wrap(err, "could not unmarshal:") }

guard m, _ := obj.(map[string]interface{}) else { return errors.New("unexpected data format") }

guard val, _ := m["key"] else { return errors.New("missing key") }

इम्हो हर कोई यहां समस्याओं की एक विस्तृत श्रृंखला पर एक साथ चर्चा कर रहा है, लेकिन वास्तविकता में सबसे आम पैटर्न "रिटर्न एरर जैसा है" है। तो क्यों न smth के साथ सबसे अधिक समस्या से संपर्क करें जैसे:

code, err ?= fn()

जिसका अर्थ है कि फ़ंक्शन गलती पर वापस आ जाना चाहिए! = शून्य?

के लिए:= ऑपरेटर हम परिचय कर सकते हैं?:=

code, err ?:= fn()

के साथ स्थिति ?:= छायांकन के कारण बदतर प्रतीत होती है, क्योंकि संकलक को चर "गलती" को उसी नाम के त्रुटि वापसी मूल्य में पारित करना होगा।

मैं वास्तव में बहुत उत्साहित हूं कि कुछ लोग केवल गलत कोड को छोटा करने के बजाय सही कोड लिखना आसान बनाने पर ध्यान केंद्रित कर रहे हैं।

कुछ नोट:

त्रुटि मॉडल पर माइक्रोसॉफ्ट में मिडोरी के डिजाइनरों में से एक से एक दिलचस्प "अनुभव रिपोर्ट" ।

मुझे लगता है कि इस दस्तावेज़ और स्विफ्ट से कुछ विचार Go2 पर खूबसूरती से लागू हो सकते हैं।

एक नया संशोधित throws कीवर्ड पेश करते हुए, फ़ंक्शंस को इस तरह परिभाषित किया जा सकता है:

func Get() []byte throws {
  if (...) {
    raise errors.New("oops")
  }

  return []byte{...}
}

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

func ScrapeDate() time.Time throws {
  body := Get() // compilation error, unhandled throwable
  body := try Get() // we've been explicit about potential throwable

  // ...
}

उन मामलों के लिए जब हम जानते हैं कि कोई विधि विफल नहीं होगी, या परीक्षणों में, हम try! को स्विफ्ट के समान पेश कर सकते हैं।

func GetWillNotFail() time.Time {
  body := Get() // compilation error, throwable not handled
  body := try Get() // compilation error, throwable can not be propagated, because `GetWillNotFail` is not annotated with throws
  body := try! Get() // works, but will panic on throws != nil

  // ...
}

हालांकि इनके बारे में निश्चित नहीं है (स्विफ्ट के समान):

func main() {
  // 1:
  do {
    fmt.Printf("%v", try ScrapeDate())
  } catch err { // err contains caught throwable
    // ...
  }

  // 2:
  do {
    fmt.Printf("%v", try ScrapeDate())
  } catch err.(type) { // similar to a switch statement
    case error:
      // ...
    case io.EOF
      // ...
  }
}

ps1. एकाधिक वापसी मूल्य func ReadRune() (ch Rune, size int) throws { ... }
ps2. हम return try Get() या return try! Get() साथ वापस आ सकते हैं
ps3. अब हम buffer.NewBuffer(try Get()) या buffer.NewBuffer(try! Get()) जैसे चेन कॉल कर सकते हैं
पीएस4. एनोटेशन के बारे में निश्चित नहीं है ( errors.Wrap(err, "context") लिखने का आसान तरीका)
ps5. ये वास्तव में अपवाद हैं
पीएस6. अनदेखी अपवादों के लिए सबसे बड़ी जीत संकलन समय त्रुटियां हैं

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

BTW, त्रुटियों की जाँच के लिए बाध्य करने और अनदेखा न करने का आपका इरादा हो सकता है
गैर-त्रुटि प्रकारों पर भी लागू होता है और अधिक में बेहतर होता है
सामान्यीकृत रूप (जैसे gcc __attribute__((warn_unused_result)))।

जहां तक ​​संचालिका के रूप का संबंध है, मैं या तो संक्षिप्त रूप सुझाऊंगा या
कीवर्ड फॉर्म इस तरह:

?= fn() या fn() की जांच करें - कॉलर को त्रुटि प्रचारित करें
!= fn() या nofail fn() -- त्रुटि पर घबराहट

पर 12:15 PM पर शनि, 26 अगस्त, 2017 पर, nvartolomei [email protected]
लिखा था:

कुछ नोट:

एक दिलचस्प अनुभव रिपोर्ट
http://joeduffyblog.com/2016/02/07/the-error-model/ इनमें से किसी एक से
त्रुटि मॉडल पर Microsoft में Midori के डिज़ाइनर।

मुझे लगता है कि इस दस्तावेज़ और स्विफ्ट से कुछ विचार
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html
Go2 को खूबसूरती से लागू कर सकते हैं।

एक नया संशोधित थ्रो कीवर्ड पेश करते हुए, कार्यों को इस प्रकार परिभाषित किया जा सकता है:

func प्राप्त करें () [] बाइट फेंकता है {
अगर (...) {
त्रुटियाँ बढ़ाएँ। नया ("उफ़")
}

वापसी [] बाइट{...}
}

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

func स्क्रैपडेट () समय। समय फेंकता है {
शरीर: = प्राप्त करें () // संकलन त्रुटि, बिना क्रिया के फेंकने योग्य
शरीर: = प्राप्त करने का प्रयास करें () // हम संभावित फेंकने योग्य के बारे में स्पष्ट हैं

//...
}

उन मामलों के लिए जब हम जानते हैं कि कोई विधि विफल नहीं होगी, या परीक्षणों में, हम कर सकते हैं
परिचय कोशिश करो! तेज के समान।

func GetWillNotFail () समय। समय {
शरीर: = प्राप्त करें () // संकलन त्रुटि, फेंकने योग्य नहीं संभाला
बॉडी: = कोशिश करें () // संकलन त्रुटि, फेंकने योग्य प्रचारित नहीं किया जा सकता है, क्योंकि GetWillNotFail को थ्रो के साथ एनोटेट नहीं किया जाता है
शरीर: = कोशिश करो! Get () // काम करता है, लेकिन थ्रो पर घबराएगा! = nil

//...
}

हालांकि इनके बारे में निश्चित नहीं है (स्विफ्ट के समान):

func मुख्य () {
// 1:
करना {
fmt.Printf("%v", ScrapeDate () का प्रयास करें)
} कैच एरर {// एरर में कैच थ्रो करने योग्य शामिल है
//...
}

// 2:
करना {
fmt.Printf("%v", ScrapeDate() का प्रयास करें)
} गलती पकड़ें। (प्रकार) {// एक स्विच स्टेटमेंट के समान
केस त्रुटि:
//...
मामला io.EOF
//...
}
}

ps1. एकाधिक वापसी मान func ReadRune () (ch रूण, आकार int) फेंकता {
...}
ps2. हम वापसी की कोशिश के साथ वापस आ सकते हैं () या वापसी की कोशिश करो! प्राप्त()
ps3. अब हम बफ़र जैसे चेन कॉल कर सकते हैं। न्यूबफ़र (गेट ()) या बफर की कोशिश करें। न्यूबफ़र (कोशिश करें!
प्राप्त())
पीएस4. टिप्पणियों के बारे में निश्चित नहीं है

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/21161#issuecomment-325106225 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AICzv9CLN77RmPceCqvjXVE_UZ6o7JGvks5sb-IYgaJpZM4Oi1c-
.

मुझे लगता है कि @jba और @bcmills द्वारा प्रस्तावित ऑपरेटर एक बहुत अच्छा विचार है, हालांकि यह "??" के रूप में बेहतर वर्तनी पढ़ता है। "=?" के बजाय आईएमओ।

इस उदाहरण को देखते हुए:

func doStuff() (int,error) {
    x, err := f() 
    if err != nil {
        return 0, wrapError("f failed", err)
    }

    y, err := g(x)
    if err != nil {
        return 0, wrapError("g failed", err)
    }

    return y, nil
}

func doStuff2() (int,error) {
    x := f()  ?? (err error) { return 0, wrapError("f failed", err) }
    y := g(x) ?? (err error) { return 0, wrapError("g failed", err) }
    return y, nil
}

मुझे लगता है कि doStuff2 पढ़ने में काफी आसान और तेज है क्योंकि यह:

1. कम ऊर्ध्वाधर स्थान बर्बाद करता है
2. बाईं ओर हैप्पी पाथ को जल्दी से पढ़ना आसान है
3. दाईं ओर त्रुटि की स्थिति को जल्दी से पढ़ना आसान है
4. फ़ंक्शन के स्थानीय नाम स्थान को प्रदूषित करने वाला कोई त्रुटि चर नहीं है

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

नए ऑपरेटरों को उनकी स्थिति और प्रकार के आधार पर वापसी मूल्यों को संभालने के लिए जोड़ना एक हैक जैसा दिखता है।

29 अगस्त को 2017, 13:03 0300, माइकल Gustavsson [email protected] ने लिखा है:

मुझे लगता है कि @jba और @bcmills द्वारा प्रस्तावित ऑपरेटर एक बहुत अच्छा विचार है, हालांकि यह "??" के रूप में बेहतर वर्तनी पढ़ता है। "=?" के बजाय आईएमओ।
इस उदाहरण को देखते हुए:
func doStuff () (इंट, एरर) {
एक्स, गलती: = एफ ()
अगर गलती!= शून्य {
वापसी 0, लपेटो त्रुटि ("एफ विफल", त्रुटि)
}

   y, err := g(x)
   if err != nil {
           return 0, wrapError("g failed", err)
   }

   return y, nil

}

func doStuff2 () (इंट, एरर) {
एक्स: = एफ () ?? (त्रुटि त्रुटि) {वापसी 0, आवरण त्रुटि ("f विफल", त्रुटि)}
वाई: = जी (एक्स) ?? (त्रुटि त्रुटि) {वापसी 0, आवरण त्रुटि ("जी विफल", त्रुटि)}
वापसी वाई, शून्य
}
मुझे लगता है कि doStuff2 पढ़ने में काफी आसान और तेज है क्योंकि यह:

1. कम ऊर्ध्वाधर स्थान बर्बाद करता है
2. बाईं ओर हैप्पी पाथ को जल्दी से पढ़ना आसान है
3. दाईं ओर त्रुटि की स्थिति को जल्दी से पढ़ना आसान है
4. फ़ंक्शन के स्थानीय नाम स्थान को प्रदूषित करने वाला कोई त्रुटि चर नहीं है

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

@nvartolomei

?? ऑपरेटर को कैसे परिभाषित किया जाएगा?

https://github.com/golang/go/issues/21161#issuecomment -319434101 और https://github.com/golang/go/issues/21161#issuecomment -320758279 देखें।

चूंकि @bcmills ने एक मौन धागे को पुनर्जीवित करने की सिफारिश की है, यदि हम अन्य भाषाओं से @slvmnd का उदाहरण लेने के लिए, कथन संशोधक के साथ फिर से करें:

func doStuff() (int, err) {
        x, err := f()
        return 0, wrapError("f failed", err)     if err != nil

    y, err := g(x)
        return 0, wrapError("g failed", err)     if err != nil

        return y, nil
}

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

हालांकि, मैं यहां पर्ल से पालना की अनुशंसा नहीं करता। (बेसिक प्लस 2 ठीक है) इस तरह लूपिंग स्टेटमेंट संशोधक निहित है, जो कभी-कभी उपयोगी होते हुए भी काफी जटिल मुद्दों का एक और सेट लाता है।

एक छोटा संस्करण:
अगर गलती हो तो वापस लौटें! = शून्य
तब भी समर्थन किया जाना चाहिए।

ऐसे वाक्य-विन्यास के साथ प्रश्न उठता है - क्या गैर-वापसी विवरण भी होना चाहिए
इस तरह के "अगर" बयानों के साथ समर्थित है, जैसे:
func(args) अगर शर्त

शायद कार्रवाई के बाद का आविष्कार करने के बजाय-अगर यह एकल शुरू करने लायक है
लाइन अगर है?

अगर गलती!=शून्य वापसी
अगर गलती! = शून्य वापसी 0, लपेटो त्रुटि ("विफल", गलती)
अगर गलती!=शून्य do_smth ()

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

लेकिन... यह सब सिर्फ छोटे बदलाव हैं और त्रुटि के लिए विशेष लैंग समर्थन नहीं है
संभालना/प्रसार करना।

सोम सितम्बर 18, 2017 पर 4:14 प्रधानमंत्री पर dsugalski [email protected] लिखा है:

चूँकि @bcmills https://github.com/bcmills ने पुनरुत्थित करने की अनुशंसा की थी a
मौन धागा, अगर हम अन्य भाषाओं से क्रिबिंग पर विचार करने जा रहे हैं,
ऐसा लगता है जैसे कथन संशोधक सभी के लिए एक उचित समाधान प्रदान करेगा
यह। @slvmnd https://github.com/slvmnd का उदाहरण लेने के लिए, इसके साथ फिर से करें
कथन संशोधक:

func doStuff () (इंट, इरेट) {
एक्स, गलती: = एफ ()
रिटर्न 0, रैपएरर ("एफ फेल", इरेट) अगर इरेट! = nil

  y, err := g(x)
    return 0, wrapError("g failed", err)     if err != nil

    return y, nil

}

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

हालांकि, मैं यहां पर्ल से पालना की अनुशंसा नहीं करता। (बेसिक प्लस 2 is
ठीक) इस तरह लूपिंग स्टेटमेंट संशोधक निहित है, जबकि कभी-कभी
उपयोगी, काफी जटिल मुद्दों का एक और सेट लाएं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/21161#issuecomment-330215402 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AICzv1rfnXeGVRRwaigCyyVK_STj-i83ks5sjmylgaJpZM4Oi1c-
.

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

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

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

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

return 0, wrapError("f failed", err) if err != nil लिखा जा सकता है if err != nil { return 0, wrapError("f failed", err) }

if err != nil return 0, wrapError("f failed", err) वही लिखा जा सकता है।

हो सकता है कि यहाँ केवल इतना आवश्यक है कि gofmt को छोड़ दिया जाए if एक ही पंक्ति पर एक पंक्ति पर तीन पंक्तियों में विस्तार करने के बजाय लिखा गया है?

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

उदाहरण के लिए, मैं http.Client.Do को एक नए अनुरोध ऑब्जेक्ट पर कॉल नहीं कर सकता, पहले http.NewRequest परिणाम को एक अस्थायी चर के लिए निर्दिष्ट किए बिना, फिर उस पर Do को कॉल करें।

मुझे आश्चर्य है कि क्या हम अनुमति दे सकते हैं:

f(y())

काम करने के लिए भले ही y (T, error) tuple लौटाए। जब y एक त्रुटि देता है, तो संकलक अभिव्यक्ति मूल्यांकन को रोक सकता है और उस त्रुटि को f से वापस करने का कारण बन सकता है। यदि f कोई त्रुटि नहीं लौटाता है, तो उसे एक दिया जा सकता है।

तब मैं कर सकता था:

n, err := http.DefaultClient.Do(http.NewRequest("DELETE", "/foo", nil))

और यदि NewRequest या Do विफल हुआ तो त्रुटि परिणाम गैर-शून्य होगा।

हालांकि, इसकी एक महत्वपूर्ण समस्या है - उपरोक्त अभिव्यक्ति पहले से ही मान्य है यदि f दो तर्कों, या भिन्न तर्कों को स्वीकार करता है। साथ ही, ऐसा करने के लिए सटीक नियम काफी शामिल होने की संभावना है।

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

@rogpeppe या आप केवल json.NewEncoder का उपयोग कर सकते हैं

@gbbr हा हाँ, बुरा उदाहरण।

एक बेहतर उदाहरण http.Request हो सकता है। मैंने इसका उपयोग करने के लिए टिप्पणी बदल दी है।

बहुत खूब। बहुत सारे विचार कोड की पठनीयता को और भी बदतर बना रहे हैं।
मैं दृष्टिकोण के साथ ठीक हूँ

if val, err := DoMethod(); err != nil {
   // val is accessible only here
   // some code
}

केवल एक चीज वास्तव में परेशान है लौटाए गए चर का दायरा।
इस मामले में आपको val लेकिन यह if दायरे में है।
तो आपको else का उपयोग करना होगा लेकिन लिंटर इसके खिलाफ होगा (और मैं भी), और एकमात्र तरीका है

val, err := DoMethod()
if err != nil {
   // some code
}
// some code with val

if ब्लॉक से बाहर चरों तक पहुंच प्राप्त करना अच्छा होगा:

if val, err := DoMethod(); err != nil {
   // some code
}
// some code with val

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

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

@gbbr
आप यहाँ किस 'यह' की बात कर रहे हैं? चीजों के बारे में कैसे जाना है, इस पर कुछ अलग सुझाव हैं।

शायद दो-भाग समाधान?

try रूप में परिभाषित करें "रिटर्न टपल में सबसे सही मान को छीलें; यदि यह इसके प्रकार के लिए शून्य मान नहीं है, तो इसे इस फ़ंक्शन के सबसे सही मान के रूप में वापस करें, जबकि अन्य शून्य पर सेट हैं"। यह आम मामला बनाता है

 a := try ErrorableFunction(b)

और जंजीर को सक्षम बनाता है

 a := try ErrorableFunction(try SomeOther(b, c))

(वैकल्पिक रूप से, दक्षता के लिए इसे गैर-शून्य के बजाय गैर-शून्य बनाएं।) यदि त्रुटिपूर्ण कार्य एक गैर-शून्य/गैर-शून्य लौटाते हैं, तो फ़ंक्शन "मान के साथ निरस्त" होता है। try 'ed फ़ंक्शन का सबसे दाहिना मान कॉलिंग फ़ंक्शन के सबसे दाहिने मान को असाइन करने योग्य होना चाहिए या यह एक संकलन-समय प्रकार की जाँच त्रुटि है। (इसलिए यह केवल error को संभालने के लिए हार्ड-कोडेड नहीं है, हालांकि शायद समुदाय को किसी अन्य "चालाक" कोड के लिए इसके उपयोग को हतोत्साहित करना चाहिए।)

फिर, डिफर जैसे कीवर्ड के साथ कोशिश रिटर्न को पकड़ने की अनुमति दें, या तो:

catch func(e error) {
    // whatever this function returns will be returned instead
}

या, अधिक मौखिक रूप से शायद लेकिन अधिक इनलाइन कि गो पहले से ही कैसे काम करता है:

defer func() {
    if err := catch(); err != nil {
        set_catch(ErrorWrapper{a, "while posting request to server"})
    }
}()

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

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

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

@thejerf इस प्रस्ताव के साथ इयान के बिंदु का हिस्सा संदर्भ जोड़ने से कार्यों को हतोत्साहित किए बिना त्रुटि बॉयलरप्लेट को संबोधित करने के तरीकों का पता लगाना है या अन्यथा उनके द्वारा लौटाई गई त्रुटियों में हेरफेर करना है।

एरर-हैंडलिंग को try और catch ऐसा लगता है कि यह उस लक्ष्य के खिलाफ चलेगा, हालांकि मुझे लगता है कि यह इस बात पर निर्भर करता है कि आमतौर पर किस तरह के डिटेल प्रोग्राम जोड़ना चाहते हैं।

कम से कम, मैं यह देखना चाहूंगा कि यह उदाहरणों के साथ कैसे काम करता है जो अधिक यथार्थवादी हैं।

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

मूल उदाहरण को फिर से लिखने के लिए,

func Chdir(dir string) error {
    if e := syscall.Chdir(dir); e != nil {
        return &PathError{"chdir", dir, e}
    }
    return nil
}

के रूप में बाहर आता है

func Chdir(dir string) error {
    catch func(e error) {
        return &PathError{"chdir", dir, e}
    }

    try syscall.Chdir(dir)
    return nil
}

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

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

मुझे यह भी संदेह है कि लोग जो चाहते हैं उनमें से अधिकांश को पूरा किया जाएगा

func SomethingBigger(dir string) (interface{}, error) {
     catch func (e error, filename string, lineno int) {
         return PackageSpecificError{e, filename, lineno, dir}
     }

     x := try Something()

     if x == true {
         try SomethingElse()
     } else {
         a, b = try AThirdThing()
     }

     return whatever, nil
}

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

मैं भी वास्तव में देखना चाहता हूँ

func packageSpecificHandler(f string) func (err error, filename string, lineno int) {
    return func (err error, filename string, lineno int) {
        return &PackageSpecificError{"In function " + f, err, filename, lineno}
    }
}

 func SomethingBigger(dir string) (interface{}, error) {
     catch packageSpecificHandler("SomethingBigger")

     ...
 }

या कुछ समकक्ष संभव हो, जब वह काम करता है।

और, पृष्ठ के सभी प्रस्तावों में से... क्या यह अभी भी गो जैसा नहीं दिखता है? ऐसा लगता है कि वर्तमान गो की तुलना में गो अधिक है।

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

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

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

मुझे खेद है कि मैंने (अभी तक) इस पूरे धागे को नहीं पढ़ा है (यह बहुत लंबा है) लेकिन मैं देखता हूं कि लोग वैकल्पिक वाक्यविन्यास फेंक रहे हैं, इसलिए मैं अपना विचार साझा करना चाहता हूं:

a, err := helloWorld(); err? {
  return fmt.Errorf("helloWorld failed with %s", err)
}

आशा है कि मुझे ऊपर कुछ याद नहीं आया जो इसे रद्द कर देता है। मैं वादा करता हूं कि मैं किसी दिन सभी टिप्पणियों के माध्यम से प्राप्त करूंगा :)

ऑपरेटर को केवल error प्रकार पर अनुमति देनी होगी, मेरा मानना ​​​​है कि प्रकार रूपांतरण अर्थपूर्ण गड़बड़ी से बचने के लिए।

दिलचस्प, @buchanae , लेकिन क्या यह हमें बहुत कुछ मिलता है:

if a, err := helloWorld(); err != nil {
  return fmt.Errorf("helloWorld failed with %s", err)
}

मुझे लगता है कि यह a से बचने की अनुमति देगा, जबकि वर्तमान स्थिति में, यह तत्कालीन और अन्य ब्लॉकों तक सीमित है।

@ object88 आप सही कह रहे हैं, परिवर्तन सूक्ष्म, सौंदर्यपूर्ण और व्यक्तिपरक है। व्यक्तिगत रूप से, मैं इस विषय पर गो 2 से केवल एक सूक्ष्म पठनीयता परिवर्तन चाहता हूं।

व्यक्तिगत रूप से, मुझे यह अधिक पठनीय लगता है क्योंकि लाइन if शुरू नहीं होती है और इसके लिए !=nil आवश्यकता नहीं होती है। चर बाएं किनारे पर हैं जहां वे (अधिकांश?) अन्य पंक्तियों पर हैं।

a के दायरे में महान बिंदु, मैंने उस पर विचार नहीं किया था।

इस व्याकरण की अन्य सम्भावनाओं को देखते हुए ऐसा संभव प्रतीत होता है।

err := helloWorld(); err? {
  return fmt.Errorf("error: %s", err)
}

और शायद

helloWorld()? {
  return fmt.Errorf("hello world failed")
}

जो शायद वहीं हैं जहां यह अलग हो जाता है।

हो सकता है कि एक त्रुटि लौटाना गो में प्रत्येक फ़ंक्शन कॉल का हिस्सा होना चाहिए, ताकि आप कल्पना कर सकें:
```
ए: = हैलोवर्ल्ड (); गलती? {
वापसी fmt.Errorf ("हैलोवर्ल्ड विफल:% s", त्रुटि)
}

वास्तविक अपवाद हैंडलिंग के बारे में क्या? मेरा मतलब है कोशिश करो, पकड़ो, अंत में कई आधुनिक भाषाओं की तरह?

नहीं, यह कोड को निहित और अस्पष्ट बनाता है (हालांकि वास्तव में थोड़ा छोटा है)

थू, 23 नवंबर 2017 को 07:27 बजे, काम्यार मिरेमाडी नोटिफिकेशन @github.com
लिखा था:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/21161#issuecomment-346529787 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AICzvyy_kGAlcs6RmL8AKKS5deNRU4_5ks5s5PQVgaJpZM4Oi1c-
.

@mpvl के WriteToGCS उदाहरण अप-थ्रेड पर लौटते हुए, मैं (फिर से) सुझाव देना चाहता हूं कि प्रतिबद्ध/रोलबैक पैटर्न गो की त्रुटि प्रबंधन में एक बड़े बदलाव की गारंटी देने के लिए पर्याप्त सामान्य नहीं है। किसी फ़ंक्शन में पैटर्न को कैप्चर करना मुश्किल नहीं है ( खेल का मैदान लिंक ):

func runWithCommit(f, commit func() error, rollback func(error)) (err error) {
    defer func() {
        if r := recover(); r != nil {
            rollback(fmt.Errorf("panic: %v", r))
            panic(r)
        }
    }()
    if err := f(); err != nil {
        rollback(err)
        return err
    }
    return commit()
}

तब हम उदाहरण को इस प्रकार लिख सकते हैं

func writeToGCS(ctx context.Context, bucket, dst string, r io.Reader) error {
    client, err := storage.NewClient(ctx)
    if err != nil {
        return err
    }
    defer client.Close()

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    return runWithCommit(
        func() error { _, err := io.Copy(w, r); return err },
        func() error { return w.Close() },
        func(err error) { _ = w.CloseWithError(err) })
}

मैं सरल समाधान सुझाऊंगा:

func someFunc() error {
    ^err := someAction()
    ....
}

एकाधिक एकाधिक फ़ंक्शन रिटर्न के लिए:

func someFunc() error {
    result, ^err := someAction()
    ....
}

और कई वापसी तर्कों के लिए:

func someFunc() (result Result, err error) {
    var result Result
    params, ^err := someAction()
    ....
}

^ साइन का अर्थ है वापसी यदि पैरामीटर शून्य नहीं है।
मूल रूप से "यदि ऐसा होता है तो त्रुटि को ढेर में ले जाएं"

इस पद्धति की कोई कमियां?

@gladkikhartem
वापस आने से पहले कोई त्रुटि को कैसे संशोधित करेगा?

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

लेकिन साथ ही मैं उस कोड से छुटकारा पाना चाहता हूं जिसमें बहुत सारी जानकारी नहीं है और बस जगह लेता है।

if err != nil {
    return err
}

यह गो के क्लिच की तरह है - आप इसे पढ़ना नहीं चाहते, आप इसे छोड़ना चाहते हैं।

इस चर्चा में मैंने अब तक जो देखा है वह निम्नलिखित का एक संयोजन है:

1. सिंटैक्स वर्बोसिटी को कम करना
2. संदर्भ जोड़कर त्रुटि में सुधार

यह @ianlancetaylor द्वारा मूल मुद्दे के विवरण के

1. सिंटेक्स वर्बोसिटी कमी

मुझे @gladkikhartem का विचार पसंद है, यहां तक ​​कि इसके मूल रूप में भी जिसकी मैं यहां रिपोर्ट करता हूं क्योंकि इसे संपादित/विस्तारित किया गया था:

 result, ^ := someAction()

एक func के संदर्भ में:

func getOddResult() (int, error) {
    result, ^ := someResult()
    if result % 2 == 0 {
          return result + 1, nil
    }
    return result, nil
}

यह संक्षिप्त वाक्य रचना - या err^ साथ @gladkikhartem द्वारा प्रस्तावित रूप में - समस्या (1) के वाक्य रचना क्रियात्मक भाग को संबोधित करेगा।

2. त्रुटि संदर्भ

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

contextError , किसी भी तरह गो को कॉल स्टैकट्रैक को ठीक उसी बिंदु पर संलग्न करना चाहिए जहां त्रुटि बनाई गई है।

एक func उदाहरण के साथ फिर से:

func getOddResult() (int, contextError) {
    result, ^ := someResult() // here a 'contextError' is created; if the error received from 'someResult()' is also a `contextError`, the two are nested
    if result % 2 == 0 {
          return result + 1, nil
    }
    return result, nil
}

केवल प्रकार error से contextError , जिसे इस प्रकार परिभाषित किया जा सकता है:

type contextError interface {
    error
    Stack() []StackEntry
    Cause() contextError
}

(ध्यान दें कि यह Stack() https://golang.org/pkg/runtime/debug/#Stack से कैसे अलग है, क्योंकि हम यहां गोरूटीन कॉल स्टैक के गैर-बाइट्स संस्करण की उम्मीद करेंगे)

नेस्टिंग के परिणामस्वरूप Cause() विधि शून्य या पिछला contextError वापस आ जाएगी।

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

पूर्व कला:

• https://godoc.org/github.com/pkg/errors (मैं इस पैकेज को व्यापक रूप से नहीं जानता या सुझाव देता हूं कि इसे चारों ओर से तैयार किया जाना चाहिए, लेकिन यह सबसे अधिक उपयोग/ज्ञात में से एक है)

विचार के लिए सिर्फ भोजन।

@gladkikhartem @gdm85

मुझे लगता है कि आप इस प्रस्ताव के बिंदु से चूक गए हैं। प्रति इयान की मूल पोस्ट:

त्रुटि को अनदेखा करना पहले से ही आसान (शायद बहुत आसान) है (देखें #20803)। त्रुटि प्रबंधन के लिए कई मौजूदा प्रस्ताव त्रुटि को असंशोधित वापस करना आसान बनाते हैं (उदाहरण के लिए, #16225, #18721, #21146, #21155)। कुछ अतिरिक्त जानकारी के साथ त्रुटि को वापस करना आसान बनाते हैं।

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

@bcmills यदि संदर्भ (स्टैक ट्रेस के रूप में) जोड़ा जा रहा है तो अतिरिक्त जानकारी के साथ त्रुटि वापस कर दी जाती है। क्या मानव-पठनीय संदेश जैसे "रिकॉर्ड डालने में त्रुटि" को "सावधानीपूर्वक त्रुटि प्रबंधन" माना जाएगा? कैसे तय करें कि कॉल स्टैक में किस बिंदु पर ऐसे संदेश जोड़े जाने चाहिए (प्रत्येक फ़ंक्शन में, ऊपर/नीचे आदि)? त्रुटि प्रबंधन सुधारों को कोडिंग करते समय ये सभी सामान्य प्रश्न हैं।

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

"रिटर्निंग एरर अनमॉडिफाइड अक्सर गलत होता है": इसलिए मैं आलसी उपयोग के मामले के लिए एक अपग्रेड पथ का प्रस्ताव करता हूं, जो कि वही उपयोग केस है जिसे वर्तमान में हानिकारक बताया गया है।

@बीसीमिल्स
मैं 100% #20803 से सहमत हूं कि त्रुटियों को हमेशा संभाला जाना चाहिए या स्पष्ट रूप से अनदेखा किया जाना चाहिए (और मुझे नहीं पता कि यह पहले क्यों नहीं किया गया था ...)
हां, मैंने प्रस्ताव के मुद्दे को संबोधित नहीं किया और मुझे करने की जरूरत नहीं है। मुझे प्रस्तावित वास्तविक समाधान की परवाह है, इसके पीछे के इरादे नहीं, क्योंकि इरादे परिणामों से मेल नहीं खाते। और जब मैं देखता हूँ || ऐसा || सामान प्रस्तावित किया जा रहा है - यह मुझे वास्तव में दुखी करता है।

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

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

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

@gladkikhartem मैं असहमत हूं कि "स्वचालित रैपिंग" का एक रूप नेविगेट करने और क्या गलत हो रहा है यह समझने में मदद करने के लिए बहुत खराब होगा। मुझे वह भी नहीं मिलता जो आप जावा स्टैक ट्रेस में संदर्भित करते हैं (मुझे अपवादों का अनुमान है? सौंदर्य की दृष्टि से बदसूरत? क्या विशिष्ट समस्या है?), लेकिन एक रचनात्मक दिशा में चर्चा करने के लिए: "सावधानी से संभाली गई त्रुटि" की एक अच्छी परिभाषा क्या हो सकती है?

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

@gladkikhartem मुझे पता है कि यह प्रस्ताव पहले से ही सभी जगह पर है, लेकिन कृपया इसे उन लक्ष्यों पर केंद्रित रखने के लिए करें जो मैंने शुरू में निर्धारित किए थे। जैसा कि मैंने कहा था कि इस मुद्दे को पोस्ट करते समय, पहले से ही कई अलग-अलग प्रस्ताव हैं जो if err != nil { return err } सरल बनाने के बारे में हैं, और वे सिंटैक्स पर चर्चा करने का स्थान हैं जो केवल उस विशिष्ट मामले को बेहतर बनाता है। धन्यवाद।

@ianlancetaylor
क्षमा करें अगर मैंने चर्चा को इसके रास्ते से हटा दिया।

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

type MyError struct {
    Type int
    Message string
    Context string
    Err error
}

func VeryLongFunc() error {
    var err MyError
    err.Context = "general function context"


   result, ^err.Err := someAction() {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
   }

    // in case we need to make a cleanup after error

   result, ^err.Err := someAction() {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
       file.Close()
   }

   // another variant with different symbol and return statement

   result, ?err.Err := someAction() {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
       return err
   }

   // using original approach

   result, err.Err := someAction()
   if err != nil {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
       return err
   }
}

func main() {
    err := VeryLongFunc()
    if err != nil {
        e := err.(MyError)
        log.Print(e.Error(), " in ", e.Dir)
    }
}

^ प्रतीक का उपयोग त्रुटि पैरामीटर को इंगित करने के लिए किया जाता है, साथ ही "someAction () {}" के लिए त्रुटि प्रबंधन से फ़ंक्शन परिभाषा को अलग करने के लिए उपयोग किया जाता है।
{ } को छोड़ा जा सकता है यदि त्रुटि को बिना संशोधित किया जाता है

"सावधान त्रुटि प्रबंधन" को बेहतर ढंग से परिभाषित करने के लिए मेरे अपने आमंत्रण का उत्तर देने के लिए कुछ और संसाधन जोड़ना:

• https://groups.google.com/forum/#!topic/golang -nuts/dkcNS4ieIpQ
• https://blog.golang.org/errors-are-values
• https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully

वर्तमान दृष्टिकोण जितना कठिन है, मुझे लगता है कि यह विकल्पों की तुलना में कम भ्रमित करने वाला है, हालांकि एक पंक्ति यदि कथन काम कर सकता है? शायद?

blah, err := doSomething()
if err != nil: return err

...या और भी...

blah, err := doSomething()
if err != nil: return &BlahError{"Something",err}

हो सकता है कि किसी ने इसे पहले ही उठा लिया हो, लेकिन कई, कई पोस्ट हैं और मैंने उनमें से कई को पढ़ा है लेकिन सभी को नहीं। उस ने कहा, मुझे व्यक्तिगत रूप से लगता है कि निहित होने की तुलना में स्पष्ट होना बेहतर होगा।

मैं रेलवे उन्मुख प्रोग्रामिंग का प्रशंसक रहा हूं, यह विचार अमृत के with कथन से आया है।
else ब्लॉक एक बार e == nil शॉर्ट सर्किट के बाद निष्पादित किया जाएगा।

यहाँ छद्म कोड के साथ मेरा प्रस्ताव आगे है:

func Chdir(dir string) (e error) {
    with e == nil {
            e = syscall.Chdir(dir)
            e, val := foo()
            val = val + 1
            // something else
       } else {
           printf("e is not nil")
           return
       }
       return nil
}

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

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

@KamyarM
आप गो में अपवाद प्रबंधन का परिचय नहीं दे सकते, क्योंकि गो में कोई अपवाद नहीं है।
गो में try{} catch{} पेश करना C में try{} catch{} को पेश करने जैसा है - यह बिल्कुल गलत है ।

@ianlancetaylor
गो एरर हैंडलिंग को बिल्कुल नहीं बदलने के बारे में क्या है, बल्कि सिंगल-लाइन एरर हैंडलिंग के लिए इस तरह के gofmt टूल को बदलें?

err := syscall.Chdir(dir)
    if err != nil {return &PathError{"chdir", dir, err}}
err = syscall.Chdir(dir2)
    if err != nil {return err}

यह पिछड़ा संगत है और आप इसे अपनी वर्तमान परियोजनाओं पर लागू कर सकते हैं

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

@KamyarM संक्षेप में यह है, लेकिन व्यवहार में ऐसा नहीं है। मेरी राय में क्योंकि हम यहाँ स्पष्ट हैं और किसी भी गो मुहावरे को नहीं तोड़ रहे हैं।

क्यों?

1. with स्टेटमेंट के अंदर के भाव नए संस्करण की घोषणा नहीं कर सकते हैं, इसलिए यह स्पष्ट रूप से बताता है कि इरादा ब्लॉक वर्र्स से बाहर मूल्यांकन करना है।
2. with अंदर स्टेटमेंट try और catch ब्लॉक के अंदर जैसा व्यवहार करेंगे। वास्तव में यह धीमा होगा क्योंकि प्रत्येक अगले निर्देश पर इसे सबसे खराब स्थिति में with की स्थितियों का मूल्यांकन करने की आवश्यकता होती है।
3. डिज़ाइन द्वारा इरादा अत्यधिक if s को हटाना है और अपवाद हैंडलर नहीं बनाना है क्योंकि हैंडलर हमेशा स्थानीय होगा ( with की अभिव्यक्ति और else ब्लॉक)।
4. throw कारण स्टैक को खोलने की कोई आवश्यकता नहीं है

पुनश्च कृपया मुझे सुधारें अगर मैं गलत हूं।

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

@gladkikhartem
हां, इसलिए मैं इसके बजाय "रेलवे उन्मुख प्रोग्रामिंग" को अपनाने का प्रस्ताव करता हूं और कोशिश करता हूं कि खोजकर्ता को न हटाएं। यह समस्या पर हमला करने के लिए सिर्फ एक और कोण है, अन्य समाधान संकलक को स्वचालित रूप से आपके लिए if err != nil लिखने नहीं देकर इसे हल करना चाहते हैं।

with न केवल त्रुटि प्रबंधन के लिए, यह किसी भी अन्य नियंत्रण प्रवाह के लिए उपयोगी हो सकता है।

@gladkikhartem
मुझे यह स्पष्ट करने दें कि मुझे लगता है कि Try Catch Finally ब्लॉक सुंदर है। If err!=nil ... वास्तव में बदसूरत कोड है।

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

@gladkikhartem

मैं ठीक हूं अगर गो लेखक इसे गो ++ या गो # या गोजावा कहते हैं और वहां Try Catch Finally हैं;)

@KamyarM

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

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

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

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

गो अकादमिक शोध पर आधारित है; व्यक्तिगत राय मायने नहीं रखती।

Microsoft के C# कंपाइलर के प्रमुख डेवलपर्स ने भी सार्वजनिक रूप से स्वीकार किया कि _exceptions_ त्रुटियों को प्रबंधित करने का एक बुरा तरीका है, जबकि Go/Rust मॉडल को एक बेहतर विकल्प के रूप में महत्व देते हुए: http://joeduffyblog.com/2016/02/07/the-error-model/

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

@ डॉ-भयानक लेख के लिए धन्यवाद।

लेकिन मुझे कहीं भी ऐसा नहीं मिला जो एक अकादमिक भाषा के रूप में GoLang का उल्लेख करता हो।

बीटीडब्ल्यू, इस उदाहरण में, अपनी बात स्पष्ट करने के लिए

func Execute() error {
    err := Operation1()
    if err!=nil{
        return err
    }

    err = Operation2()
    if err!=nil{
        return err
    }

    err = Operation3()
    if err!=nil{
        return err
    }

    err = Operation4()
    return err
}

इस तरह सी # में अपवाद हैंडलिंग को लागू करने के समान है:

         public void Execute()
        {

            try
            {
                Operation1();
            }
            catch (Exception)
            {
                throw;
            }
            try
            {
                Operation2();
            }
            catch (Exception)
            {
                throw;
            }
            try
            {
                Operation3();
            }
            catch (Exception)
            {
                throw;
            }
            try
            {
                Operation4();
            }
            catch (Exception)
            {
                throw;
            }
        }

क्या यह सी # में अपवाद प्रबंधन का एक भयानक तरीका नहीं है? मेरा जवाब है हाँ, मैं तुम्हारे बारे में नहीं जानता! गो में मेरे पास और कोई चारा नहीं है। यह वह भयानक विकल्प या राजमार्ग है। GO में ऐसा ही है और मेरे पास कोई विकल्प नहीं है।

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

बीटीडब्ल्यू, मुझे पता है कि जीओ के पास एक गैर अनुशंसित Panic, Recover , Defer जो कि Try Catch Finally के समान है लेकिन मेरी व्यक्तिगत राय में Try Catch Finally सिंटैक्स अपवाद से निपटने का बहुत साफ और बेहतर संगठित तरीका है।

@डॉ-भयानक

कृपया इसे भी देखें:
https://github.com/manuCorp/try

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

यदि आप पाते हैं कि manucorporat/try आपके लिए काम करता है, तो कृपया इसे अपने कोड में उपयोग करें। लेकिन भाषा में try/catch जोड़ने की लागत (प्रदर्शन, भाषा जटिलता, आदि) स्वयं ट्रेडऑफ़ के लायक नहीं है।

@KamyarM
आप उदाहरण सटीक नहीं हैं। करने के लिए वैकल्पिक

    err := Operation1()
    if err!=nil {
        return err
    }
    err = Operation2()
    if err!=nil{
        return err
    }
    err = Operation3()
    if err!=nil{
        return err
    }
    return Operation4()

होगा

            Operation1();
            Operation2();
            Operation3();
            Operation4();

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

         err := Operation1()
    if err!=nil {
        log.Print("input error", err)
                fmt.Fprintf(w,"invalid input")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation2()
    if err!=nil{
        log.Print("controller error", err)
                fmt.Fprintf(w,"operation has no meaning in this context")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation3()
    if err!=nil{
        log.Print("database error", err)
                fmt.Fprintf(w,"unable to access database, try again later")
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }

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

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

हालांकि, मुझे invalid HTTP header त्रुटि नहीं चाहिए जब मेरे अनुरोध में एक विकृत JSON request body , अपवाद हैंडलिंग जादुई आग-और-भूल बटन है जो सी ++ और सी # एपीआई में प्राप्त करता है जो उपयोग करते हैं उन्हें।

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

@gladkikhartem

आपके द्वारा उल्लिखित वैकल्पिक तरीका सी # में कोड लिखने का सही तरीका है। यह कोड की केवल 4 पंक्तियाँ हैं और सुखद निष्पादन पथ दिखाती हैं। इसमें वे if err!=nil शोर नहीं हैं। यदि कोई अपवाद होता है, तो वह फ़ंक्शन जो उन अपवादों की परवाह करता है, इसे Try Catch Finally का उपयोग करके संभाल सकता है (यह वही फ़ंक्शन हो सकता है या कॉलर या कॉलर का कॉलर या कॉलर के कॉलर का कॉलर हो सकता है) ... या सिर्फ एक ईवेंट हैंडलर जो किसी एप्लिकेशन में सभी अनहेल्ड त्रुटियों को संसाधित करता है। प्रोग्रामर के पास अलग-अलग विकल्प होते हैं।)

err := Operation1()
    if err!=nil {
        log.Print("input error", err)
                fmt.Fprintf(w,"invalid input")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation2()
    if err!=nil{
        log.Print("controller error", err)
                fmt.Fprintf(w,"operation has no meaning in this context")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation3()
    if err!=nil{
        log.Print("database error", err)
                fmt.Fprintf(w,"unable to access database, try again later")
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }

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

func Chdir(dir string) error {
    if e := syscall.Chdir(dir); e != nil {
        return &PathError{"chdir", dir, e}
    }
    return nil
}

लेकिन इसे आजमाएं

func Chdir(dir string) error {
    return  syscall.Chdir(dir) ? &PathError{"chdir", dir, err}:nil;
}

func Chdir(dir string) error {
    return  syscall.Chdir(dir) ? &PathError{"chdir", dir, err};
}



md5-9bcd2745464e8d9597cba6d80c3dcf40



```go
func Chdir(dir string) error {
    n , _ := syscall.Chdir(dir):
               // something to do
               fmt.Println(n)
}

उन सभी में किसी न किसी प्रकार का अस्पष्ट जादू होता है, जो पाठक के लिए चीजों को सरल नहीं करता है। पूर्व के दो उदाहरणों में, err किसी प्रकार का छद्म कीवर्ड या स्वचालित रूप से होने वाला चर बन जाता है। बाद के दो उदाहरणों में, यह बिल्कुल स्पष्ट नहीं है कि : ऑपरेटर को क्या करना चाहिए - क्या कोई त्रुटि स्वचालित रूप से वापस आने वाली है? क्या ऑपरेटर का RHS सिंगल स्टेटमेंट या ब्लॉक है?

एफडब्ल्यूआईडब्ल्यू, मैं एक रैपर फ़ंक्शन लिखूंगा ताकि आप return newPathErr("chdir", dir, syscall.Chdir(dir)) कर सकें और यदि तीसरा पैरामीटर शून्य है तो यह स्वचालित रूप से शून्य त्रुटि लौटाएगा। :-)

IMO, "गो में त्रुटि प्रबंधन को सरल बनाने" और "अतिरिक्त प्रासंगिक जानकारी के साथ त्रुटि वापस करने" के लक्ष्यों को प्राप्त करने के लिए मैंने जो सबसे अच्छा प्रस्ताव देखा है, वह #21732 में @mrkaspa से है:

a, b, err? := f1()

इस तक फैलता है:

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

और मैं इसे इससे घबराने के लिए मजबूर कर सकता हूं:

a, b, err! := f1()

इस तक फैलता है:

if err != nil {
   panic(errors.Wrap(err, "failed"))
}

यह पिछड़ी संगतता बनाए रखेगा, और त्रुटि प्रबंधन के सभी दर्द बिंदुओं को go . में सुधार देगा

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

द? संशोधक कार्यों में बॉयलरप्लेट त्रुटि को कम करेगा और ! संशोधक उन जगहों के लिए भी ऐसा ही करेगा जहां कुछ मुख्य कार्यों जैसे अन्य भाषाओं में मुखर का उपयोग किया जाएगा।

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

उस मामले में जहां आपके पास...

func foo() (int, int, error) {
    a, b, err? := f1()
    return a, b, nil
}
func bar() (int, error) {
    a, b, err? := foo()
    return a+b, nil
}

यदि foo में कुछ गलत हो जाता है, तो bar की कॉल साइट पर, त्रुटि को बिना कोई अर्थ जोड़े, उसी टेक्स्ट के साथ दोगुना लपेट दिया जाता है। कम से कम, मुझे सुझाव के errors.Wrap भाग पर आपत्ति होगी।

लेकिन आगे विस्तार करते हुए, इसका अपेक्षित परिणाम क्या है?

func baz() (a, b int, err error) {
  a = 1
  b = 2
  a, b, err? = f1()
  return

क्या a और b फिर से शून्य मान पर असाइन किया गया है? यदि हां, तो वह जादू है, जिससे मुझे लगता है कि हमें बचना चाहिए। क्या वे पहले दिए गए मानों को पूरा करते हैं? (मुझे नामित वापसी मूल्यों की परवाह नहीं है, लेकिन इस प्रस्ताव के उद्देश्य के लिए उन्हें अभी भी माना जाना चाहिए।)

@ dup2X हाँ भाषा को हटा दें, यह इस तरह से और अधिक होना चाहिए

@ object88 यह उम्मीद करना स्वाभाविक है कि किसी त्रुटि के मामले में बाकी सब कुछ

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

सम्मान से, मैं असहमत हूं, @creker। हमारे पास गैर-शून्य त्रुटि के मामले में भी गैर-शून्य रिटर्न मानों के गो स्टडलिब में उस परिदृश्य के उदाहरण हैं, और वास्तव में कार्यात्मक हैं, जैसे कि bufio.Reader संरचना में कई फ़ंक्शन। हम गो प्रोग्रामर के रूप में सभी त्रुटियों की जांच / प्रबंधन के लिए सक्रिय रूप से प्रोत्साहित होते हैं; गैर-शून्य रिटर्न मान और त्रुटि प्राप्त करने की तुलना में त्रुटियों को अनदेखा करना अधिक प्रबल लगता है। यदि आप उद्धृत करते हैं, यदि आप एक शून्य लौटाते हैं और त्रुटि की जांच नहीं करते हैं, तो भी आप एक अमान्य मान पर काम कर सकते हैं।

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

@erwbgy
यदि आप बिना किसी उपयोगी चीज के केवल त्रुटि वापस करना चाहते हैं - तो संकलक को सभी अनचाहे त्रुटियों का इलाज करने के लिए केवल "अगर गलती! = शून्य वापसी ..." के रूप में इलाज करना बहुत आसान होगा, उदाहरण के लिए:

func doStuff() error {
    doAnotherStuff() // returns error
}

func doStuff() error {
    res := doAnotherStuff() // returns string, error
}

और अतिरिक्त पागलों की कोई आवश्यकता नहीं है? इस मामले में प्रतीक।

@ वस्तु88
मैंने यहां दिखाए गए अधिकांश त्रुटि-रैपिंग प्रस्तावों को वास्तविक कोड में लागू करने का प्रयास किया है और एक प्रमुख समस्या का सामना करना पड़ा है - कोड बहुत घना और अपठनीय हो जाता है।
यह क्या करता है कोड ऊंचाई के पक्ष में कोड चौड़ाई बलिदान करता है।
रैपिंग एरर सामान्य रूप से अगर गलती! = nil वास्तव में बेहतर पठनीयता के लिए कोड को फैलाने की अनुमति देता है, इसलिए मुझे नहीं लगता कि हमें एरर रैपिंग के लिए कुछ भी बदलना चाहिए।

@ वस्तु88

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

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

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

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

यह खेल के मैदान में काम करता है, अगर आप इसे दोबारा प्रारूपित नहीं करते हैं:

a, b, err := Frob("one string"); if err != nil { return a, b, fmt.Errorf("couldn't frob: %v", err) }
// continue doing stuff with a and b

तो मुझे ऐसा लगता है कि मूल प्रस्ताव, और ऊपर वर्णित कई अन्य, उन 100 वर्णों के लिए एक स्पष्ट शॉर्टहैंड सिंटैक्स के साथ आने की कोशिश कर रहे हैं, और gofmt को लाइनब्रेक जोड़ने और 3 लाइनों में ब्लॉक को पुन: स्वरूपित करने पर जोर देने से रोकते हैं।

तो आइए कल्पना करें कि हम बहु-पंक्ति ब्लॉक पर जोर देना बंद करने के लिए gofmt को बदलते हैं, ऊपर की रेखा से शुरू करते हैं, और इसे छोटा और स्पष्ट बनाने के तरीकों के साथ आने का प्रयास करते हैं।

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

ताकि ; if err != nil { _ } लिए शॉर्टहैंड ढूंढना छोड़ दिया जाए जहां अंडरस्कोर कोड के एक हिस्से का प्रतिनिधित्व करता है। मुझे लगता है कि किसी भी शॉर्टहैंड में स्पष्टता के लिए स्पष्ट रूप से err शामिल होना चाहिए, भले ही यह शून्य तुलना को कुछ हद तक अदृश्य बना दे, इसलिए हम ; if _ != nil { _ } लिए शॉर्टहैंड के साथ आ गए हैं।

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

a, b, err := Frob("one string") § err return a, b, fmt.Errorf("couldn't frob: %v", err)

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

यह 88 वर्ण हैं, जो 100 वर्णों की एक पंक्ति पर कुल 12 वर्णों को सहेजते हैं।

तो मेरा सवाल है: क्या यह वास्तव में करने लायक है?

संपादित करें: मुझे लगता है कि मेरी बात यह है कि, जब लोग गो के if err != nil ब्लॉक को देखते हैं और कहते हैं, "काश हम उस बकवास से छुटकारा पा सकते", 80-90% वे जिस बारे में बात कर रहे हैं वह _stuff है जो आपके पास स्वाभाविक रूप से है त्रुटियों को संभालने के लिए करने के लिए_। गो के सिंटैक्स के कारण वास्तविक ओवरहेड न्यूनतम है।

@lpar , आप अधिकतर उसी तर्क का पालन कर रहे हैं जिसे मैंने ऊपर लागू किया था, इसलिए स्वाभाविक रूप से मैं आपके तर्क से सहमत हूं। लेकिन मुझे लगता है कि आप सभी त्रुटि सामग्री को दाईं ओर रखने की दृश्य अपील को छूट देते हैं:

a, b := Frob("one string")  § err { return ... }

एक कारक द्वारा अधिक पठनीय है जो वर्णों में मात्र कमी से अधिक है।

@lpar यदि आप बहुत अधिक बेकार fmt.Errorf हटाते हैं, तो आप और भी अधिक वर्ण सहेज सकते हैं, कुछ विशेष वाक्यविन्यास में वापसी बदलें और त्रुटियों के लिए कॉल स्टैक पेश करें ताकि उनके पास वास्तविक संदर्भ हो और केवल महिमा स्ट्रिंग न हो। यह आपको कुछ इस तरह छोड़ देगा

a, b, err? := Frob("one string")

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

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

मैं चाहे के सवाल लगता है fmt.Errorf की तुलना में "बेकार" है errors.Wrap , इस मुद्दे के लिए ओर्थोगोनल है के रूप में वे दोनों कर रहे हैं के बारे में समान रूप से अत्यधिक शब्द। (वास्तविक अनुप्रयोगों में मैं या तो उपयोग नहीं करता, मैं कुछ और उपयोग करता हूं जो त्रुटि और कोड की रेखा को भी लॉग करता है जिस पर यह हुआ।)

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

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

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

@ क्रेकर

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

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

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

@जैसा

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

@ क्रेकर
त्रुटियां केवल मान हैं , और वे फ़ंक्शन इनपुट और आउटपुट का हिस्सा हैं। वे "अप्रत्याशित" नहीं हो सकते थे।
यदि आप यह जानना चाहते हैं कि फ़ंक्शन ने आपको त्रुटि क्यों दी - परीक्षण, लॉगिंग और आदि का उपयोग करें ...

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

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

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

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

@creker मैंने एक ही बिंदु बनाने

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

दो अलग-अलग शैलियों, लेकिन उद्देश्य एक ही है: अपने दिमाग में पुन: पेश करने की कोशिश कर रहा है कि उन परिस्थितियों में रनटाइम पर क्या हुआ।

इस विषय पर, अंक #19991 शायद अर्थपूर्ण त्रुटियों को परिभाषित करने की दूसरी शैली के दृष्टिकोण के लिए एक वैध सारांश बना रहा है।

सभी त्रुटि कोड को कहीं और ले जाएं ताकि आपको इसे देखने की आवश्यकता न हो

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

@ जीडीएम85

आप अंत में स्रोत कोड में पाठ खोज रहे हैं

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

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

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

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

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

@जैसा

फिर से, त्रुटियाँ बग्स को ठीक करने के लिए डेवलपर के लिए नहीं हैं

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

यह त्रुटि प्रबंधन का एक लाभ है। जावा तरीके ने डेवलपर्स को सिखाया है कि यही त्रुटि प्रबंधन है, ऐसा नहीं है।

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

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

किसी के लिए हो सकता है, मेरे लिए नहीं।

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

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

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

यह पूरी तरह से और पूरी तरह से गलत है।

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

अगर यह समझ से बाहर है तो आप शायद पूरी तरह से अलग ब्रह्मांड में रहते हैं जहां ट्रेसिंग मौजूद नहीं है।

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

अगर आपको उस तरह की जानकारी की आवश्यकता नहीं है तो इसे अनदेखा करें। यह आपको चोट नहीं पहुंचाता है।

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

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

स्टैक ट्रेस धीमे हैं

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

और सुरक्षा कारणों से खिलौना परियोजनाओं के बाहर उपयोग के लिए अनुपयुक्त

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

आप जो नहीं देखते हैं वह अभी भी आपकी पाइपलाइन के थ्रूपुट को नीचा दिखा सकता है।

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

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

असत्य।

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

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

@जैसा

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

मुझे खेद है, लेकिन यह एक निरर्थक वाक्य है जिसका मेरे द्वारा कही गई बातों से कोई लेना-देना नहीं है। इसका जवाब नहीं देंगे।

स्टैक ट्रेस धीमे हैं

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

सुरक्षा कारणों से खिलौना परियोजनाओं के बाहर उपयोग के लिए अनुपयुक्त।

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

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

बिना सोचे-समझे त्रुटि प्रसार रणनीतियों की सहायता के लिए उन्हें प्रथम श्रेणी का नागरिक बनाना एक तकनीकी बेईमानी है।

क्या आप और अधिक व्यक्तिपरक हो सकते हैं? "विचारहीन त्रुटि प्रसार रणनीतियाँ" आपने उसे कहाँ देखा?

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

फिर से, कितने से?

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

इस समय ऐसा लगता है कि मैं प्रोग्रामर के अलावा किसी और से बात कर रहा हूं। ट्रेसिंग से किसी भी और सभी सॉफ्टवेयर को फायदा होता है। यह सभी भाषाओं और सभी प्रकार के सॉफ़्टवेयर में एक सामान्य तकनीक है जो बग्स को ठीक करने में मदद करती है। यदि आप इसके बारे में अधिक जानकारी चाहते हैं तो आप विकिपीडिया पढ़ सकते हैं।

बिना किसी आम सहमति के इतनी सारी अनुत्पादक चर्चाएं होने का मतलब है कि इस मुद्दे को हल करने का कोई शानदार तरीका नहीं है।

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

@ क्रेकर
ट्रेसिंग से सभी सॉफ़्टवेयर को लाभ होता है, लेकिन यह इस बात पर निर्भर करता है कि आप
यही कारण है कि मैं उसी स्टैक ट्रेस को फिर से बनाने के लिए लॉग इन करने के लिए लिखी गई संदर्भ जानकारी के साथ लिपटे त्रुटियों का उपयोग करता हूं, लेकिन जो वास्तविक गोरआउटिन स्टैक के लिए बाध्य नहीं है, बल्कि एप्लिकेशन तर्क स्वयं ही है।
ताकि मैं सिर्फ बिल्ली कर सकूं *.log | grep "orderID=xxx" और उन क्रियाओं के वास्तविक अनुक्रम का स्टैक ट्रेस प्राप्त करें जिनके कारण त्रुटि हुई।
गो की समवर्ती प्रकृति के कारण, स्टैक ट्रेस की तुलना में समृद्ध त्रुटियां अधिक मूल्यवान हैं।

@gladkikhartem उचित तर्क लिखने के लिए समय निकालने के लिए धन्यवाद। मैं उस बातचीत से निराश होने लगा था।

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

@ क्रेकर

वास्तविक उत्पादन कोड की कल्पना करें। आप इसे कितनी त्रुटियाँ उत्पन्न करने की अपेक्षा करते हैं? [...], यह देखते हुए कि अधिकांश गो एप्लिकेशन IO बाध्य हैं, यहां तक ​​​​कि यह एक गंभीर समस्या नहीं होगी।

अच्छा है कि आप आईओ बाध्य संचालन का जिक्र करते हैं। io.Reader रीड विधि EOF पर एक स्वस्थ त्रुटि देता है। तो यह हैप्पी पाथ में बहुत कुछ होने वाला है।

@urandom

स्टैक ट्रेस अनैच्छिक रूप से एक सिस्टम प्रोफाइलिंग के लिए मूल्यवान जानकारी को उजागर करता है।

• उपयोगकर्ता नाम
• फ़ाइल सिस्टम पथ
• बैकएंड डेटाबेस प्रकार/संस्करण
• लेन-देन प्रवाह
• वस्तु संरचना
• एन्क्रिप्शन एल्गोरिदम

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

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

@ क्रेकर

मैं आपको ऐसे उदाहरण देने से बचूंगा जो और अधिक असंगति का कारण बनते हैं। मुझे खेद है कि मैंने आपको निराश किया।

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

उदाहरण 1 (नामांकित रिटर्न का उपयोग करके):

ए, गलती = कुछ (बी)
अगर गलती!= शून्य {
वापसी
}

बन जाएगा:

ए, गलती = कुछ (बी)
रिटर्न अगर गलती!= शून्य

उदाहरण 2 (नामांकित रिटर्न का उपयोग नहीं करना):

ए, गलती: = कुछ (बी)
अगर गलती!= शून्य {
वापसी ए, त्रुटि
}

बन जाएगा:

ए, गलती: = कुछ (बी)
रिटर्न अगर गलत है! = शून्य {ए, गलती}

आपके नामित वापसी उदाहरण के संबंध में, क्या आपका मतलब है ...

a, err = something(b)
returnif err != nil

@ambernardino
क्यों न केवल fmt टूल को अपडेट करें और आपको भाषा सिंटैक्स को अपडेट करने और नए, बेकार कीवर्ड जोड़ने की आवश्यकता नहीं है

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

या

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

@gladkikhartem विचार यह नहीं है कि हर बार जब आप त्रुटि का प्रचार करना चाहते हैं, तो मैं इसे पसंद करूंगा और उसी तरह काम करना चाहिए

a, err? := something(b)

@mrkaspa
विचार कोड को और अधिक पठनीय बनाना है। टाइपिंग कोड कोई समस्या नहीं है, पढ़ना है।

@gladkikhartem जंग उस दृष्टिकोण का उपयोग करता है और मुझे नहीं लगता कि यह इसे कम पठनीय बनाता है

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

@mrkaspa
और मुझे लगता है कि यह इसे कम पठनीय बनाता है, आगे क्या है? हम सबसे अच्छा समाधान खोजने की कोशिश कर रहे हैं या सिर्फ राय साझा कर रहे हैं?

@ क्रेकर
'?' चरित्र पाठक पर संज्ञानात्मक भार जोड़ता है, क्योंकि यह इतना स्पष्ट नहीं है कि क्या लौटाया जा रहा है और निश्चित रूप से व्यक्ति को यह जानना चाहिए कि यह क्या कर रहा है। और ज़ाहिर सी बात है कि ? संकेत पाठक के मन में सवाल उठाता है।

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

a, err? := doStuff(a,b)
err? := doAnotherStuff(b,z,d,g)
a, b, err? := doVeryComplexStuff(b)

अधिक पठनीय हो जाएगा

a := doStuff(a,b)
doAnotherStuff(b,z,d,g)
a, b := doVeryComplexStuff(b)

वही जादू, टाइप करने के लिए बस कम सामान और सोचने के लिए कम सामान

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

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

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

क्या होगा यदि || एक नई त्रुटि उत्पन्न करेगा जो स्वचालित रूप से मूल त्रुटि को लपेटता है। तो उदाहरण इस प्रकार बन जाता है

func Chdir(dir string) error {
    syscall.Chdir(dir) || &PathError{"chdir", dir}
    return nil
}

err बस गायब हो जाता है और सभी रैपिंग को निहित रूप से संभाला जाता है। अब हमें उन आंतरिक त्रुटियों तक पहुँचने के लिए किसी तरह की आवश्यकता है। मुझे लगता है कि Inner() error से error इंटरफ़ेस जैसी दूसरी विधि जोड़ने से काम नहीं चलेगा। एक तरीका है unwrap(error) []error जैसे बिल्ट-इन फंक्शन को पेश करना। यह जो करता है वह सभी आंतरिक त्रुटियों का एक टुकड़ा देता है जिस क्रम में वे लपेटे गए थे। इस तरह आप किसी भी आंतरिक त्रुटि या उन पर सीमा तक पहुंच सकते हैं।

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

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

क्या मूल प्रस्ताव त्रुटि जांच की संख्या को कम करने या प्रत्येक व्यक्तिगत जांच की अवधि को कम करने के बारे में है?

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

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

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

@as प्रस्ताव इस बात का सारांश देता है कि वह क्या हासिल करने की कोशिश करता है। जो किया जा रहा है वह बहुत अच्छी तरह से परिभाषित है।

मूल के रूप में स्पष्ट, उच्चारण योग्य, या सरल

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

गो बैश नहीं है और त्रुटियों के बारे में कुछ भी "जादू" नहीं होना चाहिए।

यह पूरी तरह से निराधार है और किसी भी बात के लिए तर्क के रूप में नहीं गिना जाता है। इसका बैश से क्या लेना-देना मेरे से परे है।

@ क्रेकर
हां, मैं आपसे पूरी तरह सहमत हूं कि इस घटना ने और जादू पेश किया। मेरा उदाहरण सिर्फ एक निरंतरता है? कम सामान टाइप करने का ऑपरेटर विचार।

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

मूल || प्रस्ताव बहुत अच्छा है, और व्यावहारिक रूप से परीक्षण किया गया है, लेकिन मेरी राय में स्वरूपण बदसूरत है, मैं स्वरूपण को बदलने का सुझाव दूंगा

syscal.Chdir(dir)
    || return &PathError{"chdir", dir}

पीएस आप जादू वाक्यविन्यास के ऐसे प्रकार के बारे में क्या सोचते हैं?

syscal.Chdir(dir) {
    return &PathError{"chdir", dir}
}

@gladkikhartem दोनों पठनीयता के दृष्टिकोण से बहुत अच्छे लगते हैं लेकिन मुझे बाद वाले से बुरा लग रहा है। यह इस अजीब ब्लॉक स्कोप का परिचय देता है जिसके बारे में मुझे यकीन नहीं है।

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

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
        absPath, err := p.preparePath()
        if err != nil {
                return nil, err
        }
    fis, err := l.context.ReadDir(absPath)
    if err != nil {
        return nil, err
    } else if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0)
    if err != nil {
        if _, ok := err.(*build.NoGoError); ok {
            // There isn't any Go code here.
            return nil, nil
        }
        return nil, err
    }

    return buildPkg, nil
}

प्रस्तावित परिवर्तन इस फ़ंक्शन को कैसे साफ़ करते हैं?

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
    absPath, err? := p.preparePath()
    fis, err? := l.context.ReadDir(absPath)
    if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0)
    if err != nil {
         if _, ok := err.(*build.NoGoError); ok {
             // There isn't any Go code here.
             return nil, nil
         }
         return nil, err
    }

    return buildPkg, nil
}

@bcmills का प्रस्ताव बेहतर फिट बैठता है।

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
    absPath := p.preparePath()        =? err { return nil, err }
    fis := l.context.ReadDir(absPath) =? err { return nil, err }
    if len(fis) == 0 {
        return nil, nil
    }
    buildPkg := l.context.Import(".", absPath, 0) =? err {
        if _, ok := err.(*build.NoGoError); ok {
            // There isn't any Go code here.
            return nil, nil
        }
        return nil, err
    }
    return buildPkg, nil
}

@ वस्तु88

func (l *Loader) processDirectory(p *Package) (p *build.Package, err error) {
        absPath, err := p.preparePath() {
        return nil, fmt.Errorf("prepare path: %v", err)
    }
    fis, err := l.context.ReadDir(absPath) {
        return nil, fmt.Errorf("read dir: %v", err)
    }
    if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0) {
        err, ok := err.(*build.NoGoError)
                if !ok {
            return nil, fmt.Errorf("buildpkg: %v",err)
        }
        return nil, nil
    }
    return buildPkg, nil
}

इस पर प्रहार करते रहते हैं। हो सकता है कि हम उपयोग के अधिक पूर्ण उदाहरण के साथ आ सकें।

@erwbgy , यह मेरे लिए सबसे अच्छा लग रहा है, लेकिन मुझे विश्वास नहीं है कि भुगतान इतना अच्छा है।

• गैर-त्रुटि वापसी मान क्या हैं? क्या वे हमेशा शून्य-मूल्य हैं? यदि नामित रिटर्न के लिए पहले से असाइन किया गया मान _was_ है, तो क्या वह ओवरराइड हो जाता है? यदि नामित मान का उपयोग किसी त्रुटिपूर्ण फ़ंक्शन के परिणाम को संग्रहीत करने के लिए किया जाता है, तो क्या वह वापस आ जाता है?
• क्या ? ऑपरेटर को गैर-त्रुटि मान पर लागू किया जा सकता है? क्या मैं (!ok)? या ok!? जैसा कुछ कर सकता हूं (जो थोड़ा अजीब है, क्योंकि आप असाइनमेंट और ऑपरेशन को बंडल कर रहे हैं)? या यह सिंटैक्स केवल error ?

@rodcorsi , यह मुझे ReadDir बल्कि ReadBuildTargetDirectoryForFileInfo या ऐसा कुछ मूर्खतापूर्ण लंबा था। या शायद आपके पास बड़ी संख्या में तर्क हैं। preparePath लिए त्रुटि प्रबंधन भी स्क्रीन से दूर धकेल दिया जाएगा। सीमित क्षैतिज स्क्रीन आकार वाले डिवाइस पर (या व्यूपोर्ट जो इतना चौड़ा नहीं है, जैसे कि जीथब), आप =? भाग खो सकते हैं। हम लंबवत स्क्रॉलिंग में बहुत अच्छे हैं; क्षैतिज पर इतना नहीं।

@gladkikhartem , ऐसा लगता है कि यह error इंटरफ़ेस को लागू करने वाले कुछ (केवल अंतिम?) तर्क से जुड़ा हुआ है। यह एक फ़ंक्शन घोषणा की तरह दिखता है, और वह बस... _feels_ अजीब है। क्या कोई तरीका है कि इसे ok -स्टाइल रिटर्न वैल्यू से जोड़ा जा सकता है? कुल मिलाकर, आप केवल 1 लाइन खरीद रहे हैं।

@ वस्तु88
वर्ड-रैपिंग वास्तव में व्यापक कोड समस्याओं को हल करता है। क्या इसका व्यापक रूप से उपयोग नहीं किया जाता है?

@ ऑब्जेक्ट 88 बहुत लंबे फ़ंक्शन कॉल के संबंध में। आइए यहां मुख्य मुद्दे से निपटें। मुद्दा एरर हैंडलिंग पुश ऑफ स्क्रीन नहीं है। मुद्दा एक लंबा कार्य नाम और/या तर्कों की एक बड़ी सूची है। ऑफ स्क्रीन होने में त्रुटि प्रबंधन के बारे में कोई तर्क दिए जाने से पहले इसे ठीक करने की आवश्यकता है।

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

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

@ वस्तु88
हां, यह कोड अंतिम पैरामीटर के रूप में त्रुटि इंटरफ़ेस लौटने वाले किसी भी फ़ंक्शन के लिए काम करेगा।

लाइन सेविंग के संबंध में, आप कम संख्या में लाइनों में अधिक जानकारी नहीं डाल सकते हैं। कोड समान रूप से वितरित किया जाना चाहिए, न बहुत सघन और न ही प्रत्येक कथन के बाद स्थान होना चाहिए।
मैं सहमत हूं कि यह एक समारोह घोषणा की तरह दिखता है, लेकिन साथ ही यह मौजूदा के समान ही है अगर ...; ग़लती != nil { कथन, ताकि लोग बहुत भ्रमित न हों।

कोड चौड़ाई एक महत्वपूर्ण कारक है। क्या होगा अगर मेरे पास 80 लाइन संपादक है और 80 लाइन कोड एक फ़ंक्शन कॉल है और उसके बाद मेरे पास है ||

केवल पूर्णता के लिए मैं || सिंटैक्स, मेरी स्वचालित त्रुटि रैपिंग और गैर-त्रुटि वापसी मानों के ऑटो-शून्यिंग के साथ एक उदाहरण फेंक दूंगा

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
        absPath := p.preparePath() || errors.New("prepare path")
    fis := l.context.ReadDir(absPath) || errors.New("ReadDir")
    if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0)
    if err != nil {
        if _, ok := err.(*build.NoGoError); ok {
            // There isn't any Go code here.
            return nil, nil
        }
        return nil, err
    }

    return buildPkg, nil
}

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

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

err := func()
if err != nil {
    return err
}

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

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

@ वस्तु88

दावा यह है कि त्रुटियों के आसपास "बहुत अधिक कोड" है।

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

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

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

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

@gladkikhartem Go में पहले से ही वह समस्या है और मुझे नहीं लगता कि हम इसके बारे में कुछ कर सकते हैं। डेवलपर्स हमेशा आलसी रहेंगे जब तक कि आप उन्हें असफल संकलन या रनटाइम पैनिक के साथ मजबूर नहीं करते हैं, वैसे, गो नहीं कर रहा है।

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

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

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

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

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

जाओ त्रुटि प्रबंधन को मजबूर नहीं कर रहा है, लिंटर्स करते हैं। (शायद हमें इसके लिए सिर्फ एक लिंटर लिखना चाहिए?)

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

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

1. नए प्रस्ताव के सिंटैक्स में टेक्स्ट में रिटर्न स्टेटमेंट होना चाहिए, अन्यथा पाठक के लिए यह स्पष्ट नहीं है कि क्या हो रहा है। ( सहमत असहमत )
2. नए प्रस्ताव को ऐसे कार्यों का समर्थन करना चाहिए जो कई मान लौटाते हैं (सहमत/असहमत)
3. नए प्रस्ताव में कम जगह होनी चाहिए (1 लाइन, 2 लाइन, असहमत)
4. नया प्रस्ताव बहुत लंबी अभिव्यक्तियों को संभालने में सक्षम होना चाहिए (सहमत/असहमत)
5. त्रुटि के मामले में नए प्रस्ताव में कई बयानों की अनुमति होनी चाहिए (सहमत/असहमत)
6. .....

@creker , मेरे विकास का लगभग 75% VSCode में 15 "लैपटॉप पर किया जाता है। मैं अपनी क्षैतिज अचल संपत्ति को अधिकतम करता हूं, लेकिन अभी भी एक सीमा है, खासकर यदि मैं साथ-साथ संपादन कर रहा हूं। मैं छात्रों के बीच दांव लगाऊंगा , डेस्कटॉप की तुलना में कहीं अधिक लैपटॉप हैं। मैं भाषा की पहुंच क्षमता को सीमित नहीं करना चाहता क्योंकि हम उम्मीद करते हैं कि सभी के पास बड़े प्रारूप वाले मॉनिटर होंगे।

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

@gladkikhartem

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

यह स्पष्ट नहीं है कि simplifying error handling क्या बनता है, लेकिन मिसाल यह है कि less runes != simple । मुझे लगता है कि सादगी के लिए कुछ क्वालिफायर हैं जो एक निर्माण को मात्रात्मक तरीके से माप सकते हैं:

• निर्माण के तरीकों की संख्या व्यक्त की जाती है
• उस निर्माण की समानता अन्य निर्माण के लिए, और उन निर्माणों के बीच सामंजस्य
• निर्माण द्वारा संक्षेपित तार्किक संचालन की संख्या
• प्राकृतिक भाषा के निर्माण की समानता (अर्थात, निषेध का अभाव, आदि)

उदाहरण के लिए, मूल प्रस्ताव 2 से 3 तक त्रुटियों को प्रचारित करने के तरीकों की संख्या बढ़ाता है। यह तार्किक OR के समान है, लेकिन इसमें अलग-अलग शब्दार्थ हैं। यह कम जटिलता की सशर्त वापसी को सारांशित करता है ( copy या append , या >> कहने की तुलना में)। नई विधि पुराने की तुलना में कम स्वाभाविक है, और अगर ज़ोर से बोली जाती है तो शायद abs, err := path(foo) || return err -> if theres an error, it's returning err , जिस स्थिति में यह एक रहस्य होगा कि यदि आप लंबवत सलाखों का उपयोग करना संभव है तो इसे उसी तरह लिख सकते हैं जैसे कोड समीक्षा में जोर से कहा गया है।

@जैसा
पूरी तरह सहमत हैं कि less runes != simple ।
सरल से मेरा मतलब पठनीय और समझने योग्य है।
ताकि जो कोई परिचित नहीं है वह इसे पढ़कर समझे कि यह क्या करता है।
यह एक मजाक की तरह होना चाहिए - आपको इसे समझाने की जरूरत नहीं है।

वर्तमान त्रुटि प्रबंधन वास्तव में समझ में आता है, लेकिन यदि आपके पास बहुत अधिक if err != nil return. तो पूरी तरह से पठनीय नहीं है

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

@gladkikhartem नहीं, लिंटर आपको मजबूर नहीं करते, वे सुझाव देते हैं। यहाँ एक बड़ा अंतर है। वे वैकल्पिक हैं, गो टूलचेन का हिस्सा नहीं हैं और केवल सुझाव देते हैं। जबरदस्ती का मतलब केवल दो चीजें हो सकती हैं - संकलन या रनटाइम त्रुटि। बाकी सब कुछ एक सुझाव और चुनने का विकल्प है।

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

@जैसा

नया तरीका पुराने की तुलना में कम स्वाभाविक है, और अगर ज़ोर से बोला जाए तो शायद एब्स होगा, ग़लती := path(foo) || वापसी त्रुटि -> यदि कोई त्रुटि है, तो यह गलती से लौट रहा है, इस मामले में यह एक रहस्य होगा कि लंबवत सलाखों का उपयोग करना क्यों संभव है यदि आप इसे उसी तरह लिख सकते हैं जैसे कोड समीक्षा में जोर से कहा गया है।

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

जब आप लूप के साथ एक ही काम कर सकते हैं तो एक कॉल में स्लाइस जोड़ने का कोई तरीका क्यों है?

अगर कथन त्रुटि जांच लिखना तुच्छ है, तो मुझे आपके append कार्यान्वयन को देखने में दिलचस्पी होगी।

जब आप लूप के साथ ऐसा कर सकते हैं तो एक कॉल में पाठक से लेखक इंटरफ़ेस में सामान कॉपी करने का कोई तरीका क्यों है?

एक पाठक और लेखक एक कॉपी ऑपरेशन के स्रोतों और गंतव्यों, बफरिंग रणनीति और कभी-कभी लूप में प्रहरी मूल्यों को भी दूर कर देता है। आप उस अमूर्तता को लूप और स्लाइस के साथ व्यक्त नहीं कर सकते।

आप ये तर्क तब दे रहे हैं जब गो पहले से ही कई उदाहरणों के साथ उनका खंडन करता है।

मुझे विश्वास नहीं है कि ऐसा है, कम से कम उन उदाहरणों के साथ नहीं।

फिर से, आइए अधिक खुले हों और किसी भी चीज़ को सिर्फ इसलिए नीचे न गिराएं क्योंकि यह नया है और पहले से ही भाषा में नहीं है।

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

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

वाइड बनाम थिन स्क्रीन चीज़ के बारे में, एक और बात पर विचार करना मल्टी-टास्किंग है ।

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

@जैसा
पूरी तरह से सहमत हैं कि अधिकांश प्रस्तावित सुविधाएं अव्यावहारिक हैं, और मैं यह सोचने लगा हूं कि || तथा ? सामान मामला हो सकता है।

@ क्रेकर
कॉपी () और एपेंड () लागू करने के लिए तुच्छ कार्य नहीं हैं

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

स्क्रीन साइज़ के बारे में - यह मज़ेदार भी नहीं है, गंभीरता से। कृपया इस अप्रासंगिक चर्चा को बंद करें। आपकी स्क्रीन जितनी चाहें उतनी चौड़ी हो सकती है - आपको हमेशा इस बात की प्रायिकता होगी कि || return &PathError{Err:err} कोड का हिस्सा दिखाई नहीं देगा। बस Google शब्द "ide" और देखें कि कोड के लिए किस प्रकार का स्थान उपलब्ध है।

और कृपया दूसरो के पाठ को सोच समझ कर पढ़ें, मैंने यह नहीं कहा कि गो आपको सभी त्रुटियों को संभालने के लिए मजबूर करता है

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

@gladkikhartem गो त्रुटि प्रबंधन के मामले में कुछ भी मजबूर नहीं करता है, यही मुद्दा है। सभ्य बात है या नहीं, इससे कोई फर्क नहीं पड़ता, यह सिर्फ नाइट पिकिंग है। भले ही मेरे लिए इसका मतलब fmt.Println जैसी चीजों के अलावा सभी मामलों में सभी त्रुटियों को संभालना है।

अगर कोई गो में लिंटर का उपयोग नहीं कर रहा है - वह न्यायसंगत है

शायद हो। लेकिन अगर कुछ वास्तव में मजबूर नहीं है तो वह उड़ने वाला नहीं है। कुछ इसका इस्तेमाल करेंगे, अन्य नहीं करेंगे।

स्क्रीन साइज़ के बारे में - यह मज़ेदार भी नहीं है, गंभीरता से। कृपया इस अप्रासंगिक चर्चा को बंद करें।

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

अगर हम अपने स्क्रीन साइज की बात कर रहे हैं। विजुअल स्टूडियो कोड मुझे क्षैतिज स्थान के 270 प्रतीक देता है। मैं इस बात की वकालत नहीं करने वाला हूं कि इतनी जगह लेना सामान्य है। लेकिन जब आप टिप्पणियों और विशेष रूप से लंबे नामित फ़ील्ड प्रकारों के साथ संरचना को ध्यान में रखते हैं तो मेरा कोड आसानी से 120 प्रतीकों से अधिक हो सकता है। अगर मैं || सिंटैक्स का उपयोग करता तो यह 3-5 तर्क फ़ंक्शन कॉल और कस्टम संदेश के साथ लिपटे त्रुटि के मामले में आसानी से 100-120 में फिट होगा।

ईथर तरह अगर || जैसी कोई चीज लागू की जानी थी तो gofmt शायद आपको इसे एक पंक्ति पर लिखने के लिए मजबूर नहीं करना चाहिए। कुछ मामलों में यह बहुत अधिक जगह ले सकता है।

@erwbgy , यह मेरे लिए सबसे अच्छा लग रहा है, लेकिन मुझे विश्वास नहीं है कि भुगतान इतना अच्छा है।

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

val, err := func()
if err != nil {
    return nil, errors.WithStack(err)
}

सरल:

val, err? := func()

कुछ भी नहीं अधिक जटिल त्रुटि प्रबंधन को वर्तमान तरीके से करने से रोकता है।

गैर-त्रुटि वापसी मान क्या हैं? क्या वे हमेशा शून्य-मूल्य हैं? यदि नामित रिटर्न के लिए पहले से असाइन किया गया मान था, तो क्या वह ओवरराइड हो जाता है? यदि नामित मान का उपयोग किसी त्रुटिपूर्ण फ़ंक्शन के परिणाम को संग्रहीत करने के लिए किया जाता है, तो क्या वह वापस आ जाता है?

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

हो सकता है ? ऑपरेटर को गैर-त्रुटि मान पर लागू किया जाना चाहिए? क्या मैं कुछ ऐसा कर सकता हूँ (!ठीक)? या ठीक!? (जो थोड़ा अजीब है, क्योंकि आप असाइनमेंट और ऑपरेशन को बंडल कर रहे हैं)? या यह सिंटैक्स केवल त्रुटि के लिए अच्छा है?

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

मुझे लगता है कि अधिक पठनीय कोड के लिए "जरूरी" कार्य हताशा से बाहर हो रहे हैं।

sqlx

db.MustExec(schema)

एचटीएमएल टेम्पलेट

var t = template.Must(template.New("name").Parse("html"))

मैं पैनिक ऑपरेटर का प्रस्ताव करता हूं (सुनिश्चित नहीं है कि मुझे इसे 'ऑपरेटर' कहना चाहिए)

a,  😱 := someFunc(b)

के समान, लेकिन शायद उससे अधिक तत्काल

a, err := someFunc(b)
if err != nil {
  panic(err)
}

टाइप करना शायद बहुत मुश्किल है, हम कुछ इस तरह इस्तेमाल कर सकते हैं!, या !!, or

a,  !! := someFunc(b)

!! = maybeReturnsError()

शायद !! दहशत और! रिटर्न

मेरे 2 सेंट के लिए समय। हम स्टैक ट्रेस के लिए मानक पुस्तकालय के debug.PrintStack() का उपयोग क्यों नहीं कर सकते? स्टैक ट्रेस को केवल गहरे स्तर पर प्रिंट करने का विचार है, जहां त्रुटि हुई।

हम स्टैक ट्रेस के लिए मानक पुस्तकालय के debug.PrintStack() का उपयोग क्यों नहीं कर सकते?

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

इसके अलावा, स्टैक ट्रेस में अक्सर आंतरिक (अनएक्सपोर्टेड) ​​हेल्पर फ़ंक्शंस शामिल होते हैं। यह तब आसान होता है जब आप किसी अनपेक्षित क्रैश को डीबग करने का प्रयास कर रहे होते हैं, लेकिन सामान्य ऑपरेशन के दौरान होने वाली त्रुटियों के लिए सहायक नहीं होते हैं।

संपूर्ण प्रोग्रामिंग न्यूबीज़ के लिए सबसे उपयोगकर्ता के अनुकूल दृष्टिकोण क्या है?

मुझे सरल संस्करण मिला है। केवल एक if !err
कुछ खास नहीं, सहज ज्ञान युक्त, कोई अतिरिक्त विराम चिह्न नहीं, बहुत छोटा कोड

```जाओ
absPath, त्रुटि:= p.preparePath ()
वापसी शून्य, अगर गलती हो तो

इरेट:= doSomethingWith(absPath) अगर !err
doSomethingElse () अगर !err

कुछ करने के बावजूदऑफएर ()

// एक ही स्थान पर त्रुटि को संभालें; अगर जरुरत हो; बिना इंडेंट किए कैच-लाइक
अगर गलती {
वापसी "कोड प्रदूषण के बिना त्रुटि", त्रुटि
}
```

err := doSomethingWith(absPath) if !err
doSomethingElse() if !err

वापस स्वागत है, अच्छे पुराने MUMPS पोस्ट की स्थिति ;-)

धन्यवाद, लेकिन इसकी कोई ज़रूरत नहीं।

@dmajkic यह "अतिरिक्त प्रासंगिक जानकारी के साथ त्रुटि वापस करने" में मदद करने के लिए कुछ भी नहीं करता है।

@erwbgy इस मुद्दे का शीर्षक है _प्रस्ताव: जाओ 2: त्रुटि प्रबंधन को सरल बनाएं || गलती प्रत्यय_ मेरी टिप्पणी उस संदर्भ में थी। क्षमा करें अगर मैंने पिछली चर्चा में कदम रखा।

@cznic हाँ। पोस्ट की स्थितियां गो-वे नहीं हैं, लेकिन पूर्व स्थितियां भी प्रदूषित दिखती हैं:

if !err; err := doSomethingWith(absPath)
if !err; doSomethingElse()

@dmajkic केवल शीर्षक की तुलना में प्रस्ताव के लिए और भी कुछ है - ianlancetaylor त्रुटियों से निपटने के तीन तरीकों का वर्णन करता है और विशेष रूप से बताता है कि कुछ प्रस्ताव अतिरिक्त जानकारी के साथ त्रुटि को वापस करना आसान बनाते हैं।

@erwbgy मैं गुज़रा, वे सभी नए कीवर्ड (जैसे try() ) जोड़ने या विशेष गैर-अल्फ़ान्यूमेरिक वर्णों का उपयोग करने पर निर्भर हैं। व्यक्तिगत रूप से - मुझे यह पसंद नहीं है, क्योंकि कोड ओवरलोडेड है !"#$%& गाली देने जैसा, आक्रामक लगता है।

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

कैसे एक सशर्त स्थगित के बारे में

func something() (int, error) {
    var error err
    var oth err

    defer err != nil {
        return 0, mycustomerror("More Info", err)
    }
    defer oth != nil {
        return 1, mycustomerror("Some other case", oth)
    }

    _, err = a()
    _, err = b()
    _, err = c()
    _, oth = d()
    _, err = e()

    return 2, nil
}


func something() (int, error) {
    var error err
    var oth err

    _, err = a()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }
    _, err = b()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }
    _, err = c()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }
    _, oth = d()
    if oth != nil {
        return 1, mycustomerror("Some other case", oth)
    }
    _, err = e()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }

    return 2, nil
}

यह defer के अर्थ को महत्वपूर्ण रूप से बदल देगा - यह केवल कुछ ऐसा है जो दायरे के अंत में चलाया जाता है, ऐसा कुछ नहीं जो गुंजाइश को जल्दी से बाहर निकलने का कारण बनता है।

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

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

try (var err error){
     i, err:=DoSomething1()
     i, err=DoSomething2()
     i, err=DoSomething3()
} catch (err error){
   HandleError(err)
   // return err  // similar to throw err
} finally{
  // Do something
}

ऐसा लगता है कि मार्सेल इन पंक्तियों के साथ सोच रहा है:

• https://github.com/gopherchina/conference/blob/master/2018/1.3%20Rethinking%20Errors%20for%20Go%202.pdf

@sbinet यह कुछ भी नहीं से बेहतर है, लेकिन अगर वे केवल उसी कोशिश-पकड़ प्रतिमान का उपयोग करते हैं जिससे हर कोई इससे परिचित हो तो बेहतर है।

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

स्विफ्ट के समान दिखता है जिसमें "अपवाद" भी हैं जो अपवादों की तरह काफी काम नहीं करते हैं।

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

@ianlancetaylor मैंने अभी-अभी अन्य प्रोग्रामिंग भाषाओं जैसे कि C++, Java, C#, में ट्राई-कैच का उल्लेख किया है, न कि मेरे पास जो समाधान है। यह बेहतर था अगर GoLang के पास पहले दिन से ट्राई-कैच था, इसलिए हमें त्रुटि प्रबंधन के इस तरीके से निपटने की आवश्यकता नहीं थी (जो वास्तव में नया नहीं था। यदि आप चाहें तो आप किसी भी अन्य प्रोग्रामिंग भाषा के साथ एक ही GoLang त्रुटि प्रबंधन लिख सकते हैं। उस तरह कोड करने के लिए) लेकिन मैं जो सुझाव देता हूं वह मौजूदा पुस्तकालयों के साथ पिछड़ा संगतता रखने का एक तरीका था जो त्रुटि वस्तु वापस कर सकता है।

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

मेरा मतलब।

@KamyarM स्पष्टीकरण के लिए धन्यवाद। हमने अपवादों पर स्पष्ट रूप से विचार किया और उन्हें खारिज कर दिया। त्रुटियां असाधारण नहीं हैं; वे सभी प्रकार के पूरी तरह से सामान्य कारणों से होते हैं। https://blog.golang.org/errors-are-values

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

@urandom
जावा में अपवाद खराब नहीं हैं। समस्या खराब प्रोग्रामर के साथ है जो यह नहीं जानते कि इसका उपयोग कैसे किया जाए।

यदि आपकी भाषा में भयानक विशेषताएं हैं, तो कोई अंततः उस सुविधा का उपयोग करेगा। यदि आपकी भाषा में ऐसी कोई विशेषता नहीं है, तो 0% संभावना है। यह सरल गणित है।

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

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

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

@KamyarM क्या आपने कभी रेलवे उन्मुख प्रोग्रामिंग का उपयोग किया है? वो 'किरण?

आप अपवादों की इतनी प्रशंसा नहीं करेंगे, यदि आप इनका उपयोग करेंगे, इम्हो।

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

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

@ShalokShalom कृपया इसे जांचें:
https://mortoray.com/2013/09/12/the-true-cost-of-zero-cost-exceptions/

C/C++ से आने वाले लोग वास्तव में प्रशंसा करते हैं अपवाद न होने के लिए जाएं और
बुद्धिमानी से चुनाव करने के लिए, उन लोगों का विरोध करने के लिए जो दावा करते हैं कि यह "आधुनिक" है और
पठनीय कार्यप्रवाह के बारे में भगवान का शुक्रिया अदा करना (विशेषकर सी ++ के बाद)।

मंगलवार, 17 अप्रैल 2018 को 03:46 बजे, एंटोनेंको आर्टेम नोटिफिकेशन @github.com
लिखा था:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/21161#issuecomment-381793840 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AICzv9w608ea2fwPq_wNpTDBnKMAdAKTks5tpTtsgaJpZM4Oi1c-
.

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

अपवादों की वकालत करने वाले लोगों को यह लेख पढ़ना चाहिए: https://ckwop.me.uk/How-Exceptions-Suck.html

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

मैं अधिकांश सप्ताह जावा लिखता हूं, और मैं सशक्त रूप से गो में जावा-शैली के अपवादों को नहीं देखना चाहता, चाहे वे कितने भी उच्च प्रदर्शन क्यों न हों।

@lpar लूप के लिए सभी नहीं है, जबकि लूप, अगर एल्स, स्विच केस, ब्रेक और गोटो चीजें जारी रखता है। तब प्रोग्रामिंग भाषा से क्या बचा है?

जबकि, के लिए और अगर/अन्य में निष्पादन का प्रवाह शामिल नहीं है, अदृश्य रूप से कहीं और बिना किसी मार्कर के यह इंगित करने के लिए कि यह होगा।

क्या अलग है यदि कोई व्यक्ति GoLang में पिछले कॉलर को त्रुटि देता है और वह कॉलर उसे पिछले कॉलर को वापस कर देता है और इसी तरह आगे (बहुत सारे कोड शोर के अलावा)? हमें यह देखने के लिए कितने कोड चाहिए कि त्रुटि को कौन संभालेगा? ट्राइ-कैच के साथ भी ऐसा ही है।

प्रोग्रामर को क्या रोक सकता है? कभी-कभी फ़ंक्शन को वास्तव में किसी त्रुटि को संभालने की आवश्यकता नहीं होती है। हम केवल UI को त्रुटि पास करना चाहते हैं ताकि उपयोगकर्ता या सिस्टम व्यवस्थापक इसे हल कर सकें या समाधान ढूंढ सकें।

यदि कोई फ़ंक्शन किसी अपवाद को संभालना नहीं चाहता है तो वह केवल try-catch ब्लॉक का उपयोग नहीं करता है ताकि पिछला कॉलर इसे संभाल सके। मुझे नहीं लगता कि वाक्यविन्यास में कोई समस्या है। यह ज्यादा साफ-सुथरा भी होता है। हालांकि प्रदर्शन और इसे किसी भाषा में लागू करने का तरीका अलग है।

जैसा कि आप नीचे देख सकते हैं, हमें किसी त्रुटि से निपटने के लिए कोड की 4 पंक्तियों को जोड़ने की आवश्यकता है:

func myFunc1() error{
  // ...
  if (err){
      return err
  }
  return nil
}

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

विचार करना:

x, err := lib.SomeFunc(100, 4)
if err != nil {
  // A
}
// B

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

जावा के साथ तुलना करें:

x = SomeFunc(100, 4)

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

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

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

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

मुझे नहीं लगता कि वाक्यविन्यास में कोई समस्या है।

मुझे नहीं लगता कि कोई भी कह रहा है कि जावा-शैली अपवादों के साथ सिंटैक्स समस्या है।

@lpar , गो में शून्य

पैनिक बस ठीक होने में सक्षम हैं और थ्रो कैच-सक्षम हैं? सही?

मुझे सिर्फ एक अंतर याद है, घबराहट के साथ आप एक त्रुटि वस्तु या एक स्ट्रिंग ऑब्जेक्ट से घबरा सकते हैं या किसी अन्य प्रकार की वस्तुएं हो सकती हैं (अगर मैं गलत हूं तो मुझे सही करें) लेकिन थ्रो के साथ आप एक प्रकार की वस्तु को फेंक सकते हैं अपवाद या एक उपवर्ग केवल अपवाद का।

गो में शून्य डीरेफरेंस पैनिक क्यों बेहतर है कि जावा में NullPointerException?

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

@lpar खैर मैंने हाल ही में जावा के साथ प्रोग्राम नहीं किया है और मुझे लगता है कि यह एक नई बात है (पिछले 5 साल) लेकिन अपवाद बनाने के लिए शून्य संदर्भों से बचने के लिए सी # में सुरक्षित नेविगेशन ऑपरेटर है लेकिन गो के पास क्या है? मुझे यकीन नहीं है लेकिन मुझे लगता है कि उन स्थितियों को संभालने के लिए इसमें कुछ भी नहीं है। इसलिए यदि आप घबराहट से बचना चाहते हैं तो भी आपको कोड में उन बदसूरत नेस्टेड if-not-nil-else कथनों को जोड़ना होगा।

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

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

@lpar

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

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

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

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

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

स्टैक ट्रेस कैसे बेकार हो सकता है मैं अब नहीं।

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

यह आकस्मिक है और मुझे आपकी टिप्पणी में कोई कारण नहीं दिख रहा है कि जावा किसी भी तरह से शून्य/शून्य पर गो से भी बदतर है।

तब आप नहीं सुन रहे हैं। वापस जाएं और निहित अनुबंधों के बारे में पढ़ें।

त्रुटियों को बिना किसी स्पष्ट सशर्त बयान के प्रचारित किया जा सकता है।

और ठीक यही समस्या है -- त्रुटियों का प्रचार-प्रसार हो रहा है और प्रवाह में परिवर्तन को नियंत्रित करने के लिए कुछ भी स्पष्ट नहीं है कि यह होने जा रहा है। जाहिरा तौर पर आपको नहीं लगता कि यह कोई समस्या है, लेकिन अन्य असहमत हैं।

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

@ कामयारएम आप मूल रूप से शून्य को अनावश्यक बनाते हैं और इसके लिए पूर्ण प्रकार की सुरक्षा प्राप्त करते हैं:

https://fsharpforfunandprofit.com/posts/the-option-type/

और ठीक यही समस्या है -- त्रुटियों का प्रचार-प्रसार हो रहा है और प्रवाह में परिवर्तन को नियंत्रित करने के लिए कुछ भी स्पष्ट नहीं है कि यह होने जा रहा है।

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

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

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

तब आप नहीं सुन रहे हैं। वापस जाएं और निहित अनुबंधों के बारे में पढ़ें।

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

और ठीक यही समस्या है -- त्रुटियों का प्रचार-प्रसार हो रहा है और प्रवाह में परिवर्तन को नियंत्रित करने के लिए कुछ भी स्पष्ट नहीं है कि यह होने जा रहा है। जाहिरा तौर पर आपको नहीं लगता कि यह कोई समस्या है, लेकिन अन्य असहमत हैं।

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

और सैकड़ों गोरोइन के साथ विशाल गो निशान किसी तरह अधिक उपयोगी हैं?

गो के साथ, आप त्रुटियों का पता लगाने के स्थान के साथ उन्हें लॉग इन करके उनसे निपटते हैं। जब तक आप एक जोड़ना नहीं चुनते तब तक कोई बैकट्रेस नहीं है। मुझे केवल एक बार ऐसा करने की आवश्यकता है।

मेरे अनुभव में यह कोई समस्या नहीं है।

खैर, मेरा अनुभव अलग है, और मुझे लगता है कि ज्यादातर लोगों के अनुभव अलग-अलग हैं, और इसके प्रमाण के रूप में मैं इस तथ्य का हवाला देता हूं कि जावा 8 ने वैकल्पिक प्रकार जोड़े।

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

https://elixirforum.com/t/discussing-go-split-thread/13006/2

त्रुटि प्रबंधन के लिए मेरे 2 सेंट (क्षमा करें यदि इस तरह के विचार का उल्लेख ऊपर किया गया था)।

हम ज्यादातर मामलों में त्रुटियों को फिर से निकालना चाहते हैं। यह ऐसे स्निपेट की ओर जाता है:

a, err := fn()
if err != nil {
    return err
}
use(a)
return nil

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

a := fn()
use(a)

// or just

use(fn())

कंपाइलर err को निहित (अदृश्य) चर में बचाएगा, इसे nil लिए जांचें और आगे बढ़ें (यदि गलती == शून्य) या इसे वापस कर दें (यदि गलती! = शून्य) और अंत में शून्य लौटाएं फ़ंक्शन के निष्पादन के दौरान सामान्य रूप से लेकिन स्वचालित रूप से और निहित रूप से कोई त्रुटि नहीं होने पर फ़ंक्शन का।

यदि err को संभाला जाना चाहिए तो इसे एक स्पष्ट चर को सौंपा जाना चाहिए और इसका उपयोग किया जाना चाहिए:

a, err := fn()
if err != nil {
    doSomething(err)
} else {
    use(a)
}
return nil

त्रुटि को इस तरह दबाया जा सकता है:

a, _ := fn()
use(a)

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

err1, err2 := fn2()
if err1 != nil || err2 != nil {
    return err1, err2
}
return nil, nil

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

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

उदाहरण के लिए, यदि आप स्विफ्ट को देखते हैं, तो यह कोड संकलित नहीं होगा

func a() throws {}
func b() throws {
  a()
}

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

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

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

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

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

समझौते पर विचार क्यों करें?

@ निक-कोर्साकोव मूल प्रस्ताव (यह मुद्दा) त्रुटियों के लिए और संदर्भ जोड़ना चाहता है:

त्रुटि को अनदेखा करना पहले से ही आसान (शायद बहुत आसान) है (देखें #20803)। त्रुटि प्रबंधन के लिए कई मौजूदा प्रस्ताव त्रुटि को असंशोधित वापस करना आसान बनाते हैं (उदाहरण के लिए, #16225, #18721, #21146, #21155)। कुछ अतिरिक्त जानकारी के साथ त्रुटि को वापस करना आसान बनाते हैं।

यह टिप्पणी भी देखें।

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

एक और बाइकशेड:

func makeFile(url string) (size int, err error){
    rsp, err := http.Get(url)
    try err
    defer rsp.Body.Close()

    var data dataStruct
    dec := json.NewDecoder(rsp.Body)
    err := dec.Decode(&data)
    try errors.Errorf("could not decode %s: %v", url, err)

    f, err := os.Create(data.Path)
    try errors.Errorf("could not open file %s: %v", data.Path, err)
    defer f.Close()

    return f.Write([]byte(data.Rows))
}

try अर्थ है "खाली मान नहीं तो वापसी"। इसमें मैं मान रहा हूं कि errors.Errorf nil लौटाएगा जब गलती शून्य होगी। मुझे लगता है कि यह उतनी ही बचत के बारे में है जितनी हम उम्मीद कर सकते हैं जबकि आसान लपेटने के लक्ष्य के साथ चिपके रहते हैं।

विकल्प प्रकार एक समझदार विचार क्यों है?

मानक पुस्तकालय में स्कैनर प्रकार एक संरचना के अंदर त्रुटि स्थिति को संग्रहीत करते हैं जिनकी विधियाँ आगे बढ़ने से पहले किसी त्रुटि के अस्तित्व की जिम्मेदारी से जाँच कर सकती हैं।

type Scanner struct{
    err error
}
func (s *Scanner) Scan() bool{
   if s.err != nil{
       return false
   }
   // scanning logic
}
func (s *Scanner) Err() error{ return s.err }

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

इसके लिए भाषा में किसी रचनात्मक और विचित्र वाक्य रचना परिवर्तन या अप्रत्याशित नियंत्रण हस्तांतरण की भी आवश्यकता नहीं है।

मुझे कोशिश/पकड़ की तरह कुछ भी सुझाव देना है, जहां गलती को कोशिश {} के अंदर परिभाषित किया गया है, और यदि गलती गैर-शून्य मान पर सेट है - कोशिश {} से त्रुटि हैंडलर ब्लॉक (यदि कोई हो) से प्रवाह टूट जाता है।

आंतरिक रूप से कोई अपवाद नहीं हैं, लेकिन पूरी बात करीब होनी चाहिए
सिंटैक्स के लिए जो if err != nil break प्रत्येक पंक्ति के बाद जांच करता है जहां गलती असाइन की जा सकती है।
जैसे:

...
try(err) {
   err = doSomethig()
   err, value := doSomethingElse()
   doSomethingObliviousToErr()
   err = thirdErrorProneThing()
} 
catch(err SomeErrorType) {
   handleSomeSpecificErr(err)
}
catch(err Error) {
  panic(err)
}

मुझे पता है कि यह सी ++ जैसा दिखता है, लेकिन यह प्रत्येक पंक्ति के बाद मैन्युअल if err != nil {...} से भी प्रसिद्ध और क्लीनर है।

@जैसा

स्कैनर प्रकार काम करता है क्योंकि यह सभी काम कर रहा है, इसलिए रास्ते में अपनी त्रुटि का ट्रैक रखने का जोखिम उठा सकता है। आइए हम अपने आप से मजाक न करें कि यह एक सार्वभौमिक समाधान है, कृपया।

@carlmjohnson

यदि हम साधारण त्रुटि के लिए एक लाइनर हैंडलिंग चाहते हैं, तो हम रिटर्न स्टेटमेंट को एक लाइन ब्लॉक की शुरुआत होने की अनुमति देने के लिए सिंटैक्स को बदल सकते हैं।
यह लोगों को लिखने की अनुमति देगा:

func makeFile(url string) (size int, err error){
    rsp, err := http.Get(url)
    if err != nil return err
    defer rsp.Body.Close()

    var data dataStruct
    dec := json.NewDecoder(rsp.Body)
    err := dec.Decode(&data)
    if err != nil return errors.Errorf("could not decode %s: %v", url, err)

    f, err := os.Create(data.Path)
    if err != nil return errors.Errorf("could not open file %s: %v", data.Path, err)
    defer f.Close()

    return f.Write([]byte(data.Rows))
}

मुझे लगता है कि कल्पना को कुछ इस तरह बदला जाना चाहिए (यह काफी भोला हो सकता है :))

Block = "{" StatementList "}" | "return" Expression .

मुझे नहीं लगता कि अगर गलती से तीन की बजाय एक लाइन की जांच की जाती है तो विशेष केसिंग रिटर्न सिर्फ gofmt को बदलने से बेहतर होता है।

@urandom

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

स्कैनर दृष्टिकोण सबसे खराब चीजों में से एक है जिसे मैंने इस पूरे "त्रुटियों के मूल्य" मंत्र के संदर्भ में पढ़ा है:

1. यह हर उपयोग-मामले में बेकार है जिसके लिए बॉयलर-प्लेट को संभालने में बहुत सी त्रुटि की आवश्यकता होती है। कई बाहरी पैकेजों को कॉल करने वाले कार्य इससे लाभान्वित नहीं होंगे।
2. यह जटिल और अपरिचित अवधारणा है। इसका परिचय केवल भविष्य के पाठकों को भ्रमित करेगा और आपके कोड को जरूरत से ज्यादा जटिल बना देगा ताकि आप भाषा डिजाइन की कमी के आसपास काम कर सकें।
3. यह तर्क को छुपाता है और बिना किसी लाभ के इससे सबसे खराब (जटिल नियंत्रण प्रवाह) लेकर अपवादों के समान होने की कोशिश करता है।
4. कुछ मामलों में यह गणना संसाधनों को बर्बाद कर देगा। हर कॉल को बेकार त्रुटि जांच पर समय बर्बाद करना होगा जो सदियों पहले हुआ था।
5. यह ठीक उसी जगह को छुपाता है जहां त्रुटि हुई थी। ऐसे मामले की कल्पना करें जहां आप कुछ फ़ाइल प्रारूप को पार्स या क्रमबद्ध करते हैं। आपके पास कॉल पढ़ने/लिखने की एक श्रृंखला होगी। कल्पना कीजिए कि पहला विफल रहता है। आप कैसे बताएंगे कि वास्तव में त्रुटि कहां हुई? यह किस क्षेत्र को पार्स या क्रमबद्ध कर रहा था? "आईओ त्रुटि", "टाइमआउट" - इस मामले में ये त्रुटियां बेकार होंगी। आप प्रत्येक पढ़ने/लिखने के लिए संदर्भ प्रदान कर सकते हैं (उदाहरण के लिए फ़ील्ड नाम)। लेकिन इस बिंदु पर बेहतर यही होगा कि आप पूरे दृष्टिकोण को छोड़ दें क्योंकि यह आपके खिलाफ काम कर रहा है।

कुछ मामलों में यह गणना संसाधनों को बर्बाद कर देगा।

बेंचमार्क? वास्तव में "गणना संसाधन" क्या है?

यह ठीक उसी जगह को छुपाता है जहां त्रुटि हुई थी।

नहीं, ऐसा नहीं है, क्योंकि गैर-शून्य त्रुटियां अधिलेखित नहीं हैं

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

मेरी धारणा है कि आप दृष्टिकोण को नहीं समझते हैं। यह तार्किक रूप से एक स्व-निहित प्रकार में नियमित त्रुटि जांच के बराबर है, मेरा सुझाव है कि आप उदाहरण का बारीकी से अध्ययन करें ताकि हो सकता है कि यह आपके द्वारा _read_ की सबसे बुरी चीज के बजाय सबसे बुरी चीज हो।

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

प्रस्ताव

गैर-शून्य error मान असाइन किए जाने पर घबराहट पैदा करने के लिए सिंटैक्टिक शुगर के रूप में _! टोकन के उपयोग को सक्षम करके त्रुटि बॉयलरप्लेट को कम करें

val, err := something.MayError()
if err != nil {
    panic(err)
}

बन सकता है

val, _! := something.MayError()

तथा

if err := something.MayError(); err != nil {
    panic(err)
}

बन सकता है

_! = something.MayError()

बेशक, विशेष प्रतीक बहस के लिए तैयार है। मैंने _^ , _* , @ , और अन्य पर भी विचार किया। मैंने वास्तविक सुझाव के रूप में _! चुना क्योंकि मुझे लगा कि यह एक नज़र में सबसे परिचित होगा।

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

औचित्य

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

मुझे एहसास है कि जितना संभव हो सके घबराहट से बचना गो का दर्शन है। वे एपीआई सीमाओं में त्रुटि प्रसार के लिए एक उपकरण नहीं हैं। हालाँकि, वे भाषा की एक विशेषता हैं और उनके पास वैध उपयोग के मामले हैं, जैसे कि ऊपर वर्णित। निजी कोड में त्रुटि प्रसार को सरल बनाने के लिए पैनिक्स एक शानदार तरीका है, और सिंटैक्स का सरलीकरण कोड को क्लीनर और, यकीनन, स्पष्ट बनाने के लिए एक लंबा रास्ता तय करेगा। मुझे लगता है कि "if-error-panic" फॉर्म की तुलना में एक नज़र में _! (या @ , या `_^, etc...) को पहचानना आसान है। एक टोकन नाटकीय रूप से उस कोड की मात्रा को कम कर सकता है जिसे संप्रेषित करने/समझने के लिए लिखा/पढ़ा जाना चाहिए:

1. कोई त्रुटि हो सकती है
2. अगर कोई त्रुटि है, तो हम इसकी उम्मीद नहीं कर रहे हैं
3. अगर कोई त्रुटि है, तो शायद इसे श्रृंखला में संभाला जा रहा है

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

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

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

@carlmjohnson दो चीजों में से एक को सच होना चाहिए:

1. आतंक वैध उपयोग के मामलों वाली भाषा का एक हिस्सा है, या
2. आतंक के वैध उपयोग के मामले नहीं हैं, और इसलिए इसे भाषा से हटा दिया जाना चाहिए

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

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

दहशत कुछ विशिष्ट संवाद करती है:

यहाँ कुछ गलत हो गया जिसे संभालने के लिए यहाँ तैयार नहीं था

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

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

var1, _! := trySomeTask1()
var2, _! := trySomeTask2(var1)
var3, _! := trySomeTask3(var2)
var4, _! := trySomeTask4(var3)

की तुलना में बहुत अधिक पठनीय है

var1, err := trySomeTask1()
if err != nil {
    panic(err)
}
var2, err := trySomeTask2(var1)
if err != nil {
    panic(err)
}
var3, err := trySomeTask3(var2)
if err != nil {
    panic(err)
}
var4, err := trySomeTask4(var3)
if err != nil {
    panic(err)
}

सिंटैक्स और ऑब्जेक्ट पदानुक्रम की कमी के अलावा गो में घबराहट और जावा या पायथन आदि में अपवाद के बीच वास्तव में कोई मौलिक अंतर नहीं है (जो समझ में आता है क्योंकि गो में विरासत नहीं है)। वे कैसे काम करते हैं और उनका उपयोग कैसे किया जाता है यह वही है।

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

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

गो पैनिक्स और जावा के अनियंत्रित अपवाद काफी हद तक समान हैं और वे समान कारणों से और समान उपयोग मामलों को संभालने के लिए मौजूद हैं। लोगों को अन्य मामलों के लिए आतंक का उपयोग करने के लिए प्रोत्साहित न करें क्योंकि उन मामलों में अन्य भाषाओं में अपवादों के समान ही समस्याएं हैं।

लोग कभी-कभी स्टैक को शॉर्ट सर्किट करने के तरीके के रूप में भी पैनिक का उपयोग करते हैं, लेकिन यह आमतौर पर पठनीयता और प्रदर्शन के कारणों से परेशान होता है

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

// clearly, linearly shows that these steps must occur in order,
// and any errors returned cause a panic, because this piece of
// code isn't responsible for reporting or handling possible failures:
// - IO Error: either network or disk read/write failed
// - External service error: some unexpected response from the external service
// - etc...
// It's not this code's responsibility to be aware of or handle those scenarios.
// That's perhaps the parent process's job.
var1, _! := trySomeTask1()
var2, _! := trySomeTask2(var1)
var3, _! := trySomeTask3(var2)
var4, _! := trySomeTask4(var3)

बनाम

var1, err := trySomeTask1()
if err != nil {
    panic(err)
}
var2, err := trySomeTask2(var1)
if err != nil {
    panic(err)
}
var3, err := trySomeTask3(var2)
if err != nil {
    panic(err)
}
var4, err := trySomeTask4(var3)
if err != nil {
    panic(err)
}

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

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

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

1. इस तरह के सिंटैक्स एक्सटेंशन से आप किस गाली की कल्पना करते हैं?
2. var1, err := trySomeTask1(); if err != nil { panic(err) } क्या बताता है कि var1, _! := trySomeTask1() नहीं करता है? क्यों?

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

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

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

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

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

यहां तक ​​​​कि मेरे अपने कोड में, कई बार मैं कोड का एक टुकड़ा लिखता हूं, जिसका एकमात्र काम त्रुटियों को मूल कार्य में वापस देना है।

उदाहरण के लिए, मान लें कि आपके पास http.HandlerFunc डिस्क से एक फ़ाइल को प्रतिक्रिया के रूप में पढ़ता है - यह लगभग हमेशा काम करेगा, और यदि यह विफल हो जाता है तो संभावना है कि प्रोग्राम ठीक से लिखा नहीं गया है (प्रोग्रामर त्रुटि) या फ़ाइल सिस्टम में कोई समस्या है कार्यक्रम की जिम्मेदारी के दायरे से बाहर। एक बार http.HandlerFunc पैनिक हो जाने पर, यह बाहर निकल जाता है और कुछ बेस हैंडलर उस पैनिक को पकड़ लेंगे और क्लाइंट को 500 लिखेंगे। अगर भविष्य में किसी भी समय मैं उस त्रुटि को अलग तरीके से संभालना चाहता हूं, तो मैं _! को err से बदल सकता हूं और जो कुछ भी मैं चाहता हूं वह त्रुटि मान के साथ कर सकता हूं। बात यह है कि कार्यक्रम के जीवन के लिए, मुझे ऐसा करने की आवश्यकता नहीं होगी। अगर मैं इस तरह के मुद्दों में भाग रहा हूं, तो हैंडलर उस त्रुटि को संभालने के लिए जिम्मेदार कोड का हिस्सा नहीं है।

मैं आईओ विफलताओं, नेटवर्क विफलताओं आदि जैसी चीजों के लिए अपने हैंडलर में if err != nil { panic(err) } या if err != nil { return ..., err } लिख सकता हूं, और सामान्य रूप से करता हूं। जब मुझे किसी त्रुटि की जांच करने की आवश्यकता होती है, तब भी मैं ऐसा कर सकता हूं। अधिकांश समय, हालांकि, मैं सिर्फ if err != nil { panic(err) } लिख रहा हूं।

या, एक और उदाहरण, अगर मैं एक ट्री (http राउटर कार्यान्वयन में कहें) को दोबारा खोज रहा हूं, तो मैं एक फ़ंक्शन func (root *Node) Find(path string) (found Value, err error) घोषित करूंगा। वह फ़ंक्शन पेड़ के नीचे जाने से उत्पन्न किसी भी प्रकार की घबराहट को ठीक करने के लिए एक फ़ंक्शन को स्थगित कर देगा। क्या होगा यदि प्रोग्राम विकृत प्रयास बना रहा है? क्या होगा यदि कुछ आईओ विफल हो जाते हैं क्योंकि प्रोग्राम सही अनुमतियों वाले उपयोगकर्ता के रूप में नहीं चल रहा है? ये मुद्दे मेरे ट्राई सर्च एल्गोरिथम की समस्या नहीं हैं - जब तक कि मैं इसे बाद में स्पष्ट रूप से नहीं बनाता - लेकिन वे संभावित त्रुटियां हैं जिनका मुझे सामना करना पड़ सकता है। स्टैक पर सभी तरह से लौटने से ढेर सारी अतिरिक्त वर्बोसिटी हो जाती है, जिसमें स्टैक पर आदर्श रूप से कई शून्य त्रुटि मान होंगे। इसके बजाय, मैं उस सार्वजनिक एपीआई फ़ंक्शन तक किसी त्रुटि से घबराना और उसे उपयोगकर्ता को वापस करना चुन सकता हूं। फिलहाल, यह अभी भी उस अतिरिक्त वाचालता को लेता है, लेकिन ऐसा करने की आवश्यकता नहीं है।

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

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

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

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

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

मुझे लगता है कि तुम गलत हो। लोग आपके शॉर्टहैंड ऑपरेटर तक पहुंचेंगे क्योंकि यह बहुत सुविधाजनक है, और फिर वे पहले की तुलना में बहुत अधिक घबराहट का उपयोग करेंगे।

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

लेकिन कई मामलों में यह अंतर किए जा रहे ऑपरेशन के लिए नगण्य है

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

पहले तो नगण्य लग रहा था, यह ढेर हो जाएगा और अंततः बाद में देर होने पर सड़क के नीचे बाधाओं का कारण बन जाएगा।

जी नहीं, धन्यवाद। काल्पनिक प्रदर्शन बाधाएं ज्यामितीय रूप से नगण्य प्रदर्शन बाधाएं हैं।

जी नहीं, धन्यवाद। काल्पनिक प्रदर्शन बाधाएं ज्यामितीय रूप से नगण्य प्रदर्शन बाधाएं हैं।

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

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

दोस्तों, कृपया बातचीत को सम्मानजनक और विषय पर रखें। यह समस्या गो त्रुटियों को संभालने के बारे में है।

https://golang.org/conduct

मैं फिर से "त्रुटि वापस/अतिरिक्त संदर्भ के साथ" भाग पर फिर से जाना चाहता हूं, क्योंकि मुझे लगता है कि त्रुटि को अनदेखा करना पहले से ही मौजूदा _ द्वारा कवर किया गया है।

मैं एक दो-शब्द कीवर्ड का प्रस्ताव कर रहा हूं जिसके बाद एक स्ट्रिंग (वैकल्पिक रूप से) हो सकती है। दो शब्दों वाला कीवर्ड होने का कारण दुगना है। सबसे पहले, एक ऑपरेटर के विपरीत जो स्वाभाविक रूप से गूढ़ है, यह समझना आसान है कि यह बहुत अधिक पूर्व ज्ञान के बिना क्या करता है। मैंने "या बबल" चुना है, क्योंकि मुझे उम्मीद है कि एक निर्दिष्ट त्रुटि की अनुपस्थिति के साथ or शब्द उपयोगकर्ता को इंगित करेगा कि त्रुटि यहां नियंत्रित की जा रही है, अगर यह शून्य नहीं है। कुछ उपयोगकर्ता पहले से ही or को अन्य भाषाओं (पर्ल, पायथन) से एक झूठे मूल्य को संभालने के साथ जोड़ देंगे, और data := Foo() or ... पढ़ने से अवचेतन रूप से उन्हें बता सकता है कि data अनुपयोगी है यदि or बयान का हिस्सा पूरा हो गया है। दूसरा, bubble कीवर्ड अपेक्षाकृत छोटा होने पर, उपयोगकर्ता को संकेत दे सकता है कि कुछ ऊपर जा रहा है (ढेर)। up शब्द भी उपयुक्त हो सकता है, हालांकि मुझे यकीन नहीं है कि पूरा or up पर्याप्त समझ में आता है या नहीं। अंत में, पूरी बात एक कीवर्ड है, सबसे पहले और सबसे महत्वपूर्ण क्योंकि यह अधिक पठनीय है, और दूसरा क्योंकि वह व्यवहार किसी फ़ंक्शन द्वारा स्वयं नहीं लिखा जा सकता है (आप जिस फ़ंक्शन में हैं, उससे बचने के लिए आप घबराहट को कॉल करने में सक्षम हो सकते हैं, लेकिन फिर आप कर सकते हैं ' अपने आप को मत रोको, किसी और को ठीक होना होगा)।

निम्नलिखित केवल त्रुटि प्रसार के लिए है, इसलिए केवल उन कार्यों में उपयोग किया जा सकता है जो एक त्रुटि लौटाते हैं, और किसी अन्य वापसी तर्क के शून्य मान:

किसी त्रुटि को किसी भी तरह से संशोधित किए बिना वापस करने के लिए:

func Worker(path string) ([]byte, error) {
    data := ioutil.ReadFile(path) or bubble

    return data;
}

एक अतिरिक्त संदेश के साथ एक त्रुटि वापस करने के लिए:

func Worker(path string) ([]byte, error) {
    data := ioutil.ReadFile(path) or bubble fmt.Sprintf("reading file %s", path)

    modified := modifyData(data) or bubble "modifying the data"

    return data;
}

और अंत में, अनुकूलित त्रुटि संशोधन के लिए एक वैश्विक एडेप्टर तंत्र पेश करें:

// Default Bubble Processor
errors.BubbleProcessor(func(msg string, err error) error {
    return fmt.Errorf("%s: %v", msg, err)
})

// Some program might register the following:
errors.BubbleProcessor(func(msg string, err error) error {
    return errors.WithMessage(err, msg)
})

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

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

साथ ही, or bubble का अस्तित्व or die या or panic की संभावना का सुझाव देता है। मुझे यकीन नहीं है कि यह एक सुविधा या बग है।

एक ऑपरेटर के विपरीत जो स्वाभाविक रूप से गूढ़ है, यह समझना आसान है कि यह बहुत अधिक पूर्व ज्ञान के बिना क्या करता है

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

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

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

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

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

@ कामयार , मैं सम्मानपूर्वक असहमत हूं; कोशिश/पकड़ _not_ सभी को खुश करता है। यहां तक ​​​​कि अगर आप इसे अपने कोड में लागू करना चाहते हैं, तो फेंके गए अपवाद का मतलब है कि आपके कोड का उपयोग करने वाले प्रत्येक व्यक्ति को अपवादों को संभालने की आवश्यकता है। यह कोई भाषा परिवर्तन नहीं है जिसे आपके कोड में स्थानीयकृत किया जा सकता है।

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

हालांकि शायद आप एक संक्षिप्त उदाहरण प्रदान कर सकते हैं, शायद कुछ ऐसा है जो मुझे याद आ रहा है।

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

यह शायद इस मामले से संबंधित नहीं है, लेकिन मैं सी ++ के टर्नरी ऑपरेटर के समकक्ष गो के लिए एक और दिन देख रहा था और मैं इस वैकल्पिक दृष्टिकोण पर आया:

वी: = नक्शा [बूल] इंट {सच: पहला_एक्सप्रेशन, झूठा: दूसरा_एक्सप्रेशन} [शर्त]
बस के बजाय
वी = शर्त? फर्स्ट_एक्सप्रेशन: सेकेंड_एक्सप्रेशन;

आप लोगों को दो रूपों में से कौन-सा पसंद है? ऊपर एक अपठनीय कोड (गो माई वे) शायद बहुत सारे प्रदर्शन मुद्दों या सी ++ (राजमार्ग) में दूसरा सरल वाक्यविन्यास के साथ? मुझे हाईवे वाले लोग पसंद हैं। मैं तुम्हारे बारे में नहीं जानता।

तो संक्षेप में बताने के लिए कृपया नए सिंटैक्स लाएं, उन्हें अन्य प्रोग्रामिंग भाषाओं से उधार लें। उसके साथ कुछ भी गलत नहीं है।

सादर,

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

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

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

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

@urandom , शायद यह एक मामूली उदाहरण है, लेकिन error , जिसे मैं अपने कोड में कहीं और उपभोग करने की अपेक्षा करता हूं। यदि कोई अन्य एडॉप्टर साथ आता है और मेरे एडॉप्टर को बदल देता है, तो मेरा कोड सही ढंग से काम करना बंद कर देता है।

@KamyarM भाषा और उसके मुहावरे एक साथ चलते हैं। जब हम एरर-हैंडलिंग में बदलाव पर विचार करते हैं, तो हम न केवल सिंटैक्स को बदलने के बारे में बात कर रहे हैं, बल्कि (संभावित रूप से) कोड की संरचना की भी बात कर रहे हैं।

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

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

    var v int
    if condition {
        v = first_expression
    } else {
        v = second_expression
    }

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

@KamyarM मैं गो और जावा दोनों का उपयोग करता हूं, और मैं जोरदार रूप से _do not_ चाहता हूं कि जावा से अपवाद हैंडलिंग की प्रतिलिपि बनाई जाए। यदि आप जावा चाहते हैं, तो जावा का उपयोग करें। और कृपया टर्नरी ऑपरेटरों की चर्चा को एक उपयुक्त मुद्दे पर ले जाएं, जैसे #23248।

@lpar तो अगर मैं किसी कंपनी के लिए काम करता हूं और किसी अज्ञात कारण से उन्होंने GoLang को अपनी प्रोग्रामिंग भाषा के रूप में चुना है, तो मुझे बस अपनी नौकरी छोड़ने और जावा के लिए आवेदन करने की आवश्यकता है !? आ जाओ भाई!

@bcmills आप वहां सुझाए गए कोड को गिन सकते हैं। मुझे लगता है कि एक के बजाय कोड की 6 लाइनें हैं और शायद आपको इसके लिए कुछ कोड साइक्लोमैटिक जटिलता बिंदु मिलते हैं (आप लोग लिंटर का उपयोग करते हैं। सही?)।

@carlmjohnson और @bcmills कोई भी सिंटैक्स जो पुराना और परिपक्व है, इसका मतलब यह नहीं है कि वह खराब है। असल में मुझे लगता है कि अगर अन्य वाक्यविन्यास टर्नरी ऑपरेटर सिंटैक्स से पुराना है।

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

@KamyarM कृपया विनम्र https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html की अनुशंसा करता हूं

साथ ही, एक सामान्य टिप्पणी, कोशिश/पकड़ की हालिया चर्चा से असंबंधित।

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

अगर कोई चर्चा की गई समस्याओं की एक संगठित और सारांशित सूची को बनाए रखने के लिए अविश्वसनीय लेकिन महत्वपूर्ण कार्य करना चाहता है तो मैं भी उत्साहित हूं।

@ जोशेरियन मैं वहीं खुलकर बात कर रहा था। मैं सटीक मुद्दों को भाषा या समुदाय में दिखाना चाहता था। इसे अधिक आलोचना मानें। GoLang आलोचना के लिए खुला है, क्या यह सही है?

@KamyarM यदि आपने किसी ऐसी कंपनी के लिए काम किया है जिसने अपनी प्रोग्रामिंग भाषा के लिए रस्ट को चुना था, तो क्या आप रस्ट

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

टर्नरी एक्सप्रेशन के बारे में भी यही सच है। गो के इतिहास पर पढ़ें - गो के रचनाकारों में से एक केन थॉम्पसन ने 1969 में बेल लैब्स में बी भाषा (सी के पूर्ववर्ती) में टर्नरी ऑपरेटर को लागू किया। मुझे लगता है कि यह कहना सुरक्षित है कि विचार करते समय उन्हें इसके लाभों और नुकसानों के बारे में पता था। क्या इसे गो में शामिल करना है।

गो आलोचना के लिए खुला है लेकिन हम चाहते हैं कि गो मंचों में चर्चा विनम्र हो। स्पष्टवादी होना असभ्य होने के समान नहीं है। https://golang.org/conduct का "गोफर मान" अनुभाग

@lpar हां, अगर जंग के पास ऐसा कोई मंच है तो मैं ऐसा करूंगा ;-) गंभीरता से मैं ऐसा करूंगा। क्योंकि मैं चाहता हूं कि मेरी आवाज सुनी जाए।

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

@josharian लेख के लिए धन्यवाद, मैं उस पर एक नज़र

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

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

मैं इस विषय पर अधिक चर्चा करने से स्वयं को मुक्त कर लूंगा।

इस मौके के लिए आपका शुक्रिया।

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

एक बार फिर: कृपया विनम्र रहें। तकनीकी तर्कों पर टिके रहें। ऐसे विज्ञापन घरेलू तर्कों से बचें जो विचारों के बजाय लोगों पर हमला करते हैं। यदि आप वास्तव में मेरा मतलब नहीं समझते हैं, तो मैं इस पर ऑफ़लाइन चर्चा करने को तैयार हूं; मुझे ईमेल करो। धन्यवाद।

मैं अपना 2c अंदर फेंक दूंगा, और आशा करता हूं कि यह सचमुच अन्य एन सौ टिप्पणियों में कुछ दोहरा नहीं रहा है (या urandom के प्रस्ताव की चर्चा पर कदम उठा रहा है)।

मुझे मूल विचार पसंद है जो पोस्ट किया गया था, लेकिन दो प्राथमिक बदलावों के साथ:

• सिंटैक्टिक बाइकशेडिंग: मेरा दृढ़ विश्वास है कि किसी भी चीज में निहित नियंत्रण प्रवाह मौजूदा ऑपरेटर के अधिभार के बजाय अपने आप में एक ऑपरेटर होना चाहिए। मैं वहां ?! फेंक दूंगा, लेकिन गो में मौजूदा ऑपरेटर के साथ आसानी से भ्रमित नहीं होने वाली चीज़ों से मैं खुश हूं।

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

func returnErrorf(s string, args ...interface{}) func(error) error {
  return func(err error) error {
    return errors.New(fmt.Sprintf(s, args...) + ": " + err.Error())
  }
}

func foo(r io.ReadCloser, callAfterClosing func() error, bs []byte) ([]byte, error) {
  // If r.Read fails, returns `nil, errors.New("reading from r: " + err.Error())`
  n := r.Read(bs) ?! returnErrorf("reading from r")
  bs = bs[:n]
  // If r.Close() fails, returns `nil, errors.New("closing r after reading [[bs's contents]]: " + err.Error())`
  r.Close() ?! returnErrorf("closing r after reading %q", string(bs))
  // Not that I advocate this inline-func approach, but...
  callAfterClosing() ?! func(err error) error { return errors.New("oh no!") }
  return bs, nil
}

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

अधिक दिलचस्प मामलों में काम करने के लिए इस पैटर्न को "ओवरलोड" करना भी बहुत सरल है। मेरे मन में तीन उदाहरण हैं।

सबसे पहले, हम return सशर्त हो सकते हैं यदि आरएचएस एक func(error) (error, bool) , जैसे (यदि हम इसकी अनुमति देते हैं, तो मुझे लगता है कि हमें बिना शर्त रिटर्न से एक अलग ऑपरेटर का उपयोग करना चाहिए। मैं ?? , लेकिन मेरा "मुझे तब तक परवाह नहीं है जब तक यह अलग है" कथन अभी भी लागू होता है):

func maybeReturnError(err error) (error, bool) {
  if err == io.EOF {
    return nil, false
  }
  return err, true
}

func id(err error) error { return err }

func ignoreError(err error) (error, bool) { return nil, false }

func foo(n int) error {
  // Does nothing
  id(io.EOF) ?? ignoreError
  // Still does nothing
  id(io.EOF) ?? maybeReturnError
  // Returns the given error
  id(errors.New("oh no")) ?? maybeReturnError
  return nil
}

वैकल्पिक रूप से, हम RHS फ़ंक्शंस को स्वीकार कर सकते हैं जिनके रिटर्न प्रकार बाहरी फ़ंक्शन से मेल खाते हैं, जैसे:

func foo(r io.Reader) ([]int, error) {
  returnError := func(err error) ([]int, error) { return []int{0}, err }
  // returns `[]int{0}, err` on a Read failure
  n := r.Read(make([]byte, 4)) ?! returnError
  return []int{n}, nil
}

और अंत में, यदि हम वास्तव में चाहते हैं, तो हम तर्क प्रकार को बदलकर इसे केवल त्रुटियों से अधिक के साथ काम करने के लिए सामान्यीकृत कर सकते हैं:

func returnOpFailed(name string) func(bool) error {
  return func(_ bool) error {
    return errors.New(name + " failed")
  }
}

func returnErrOpFailed(name string) func(error) error {
  return func(err error) error {
    return errors.New(name + " failed: " + err.Error())
  }
}

func foo(c chan int, readInt func() (int, error), d map[int]string) (string, error) {
  n := <-c ?! returnOpFailed("receiving from channel")
  m := readInt() ?! returnErrOpFailed("reading an int")
  result := d[n + m] ?! returnOpFailed("looking up the number")
  return result, nil
}

...जो मुझे व्यक्तिगत रूप से तब उपयोगी लगेगा जब मुझे कुछ भयानक करना होगा, जैसे map[string]interface{} हाथ से डिकोड करना।

स्पष्ट होने के लिए, मैं मुख्य रूप से एक्सटेंशन को उदाहरण के रूप में दिखा रहा हूं। मुझे यकीन नहीं है कि उनमें से कौन (यदि कोई हो) सादगी, स्पष्टता और सामान्य उपयोगिता के बीच एक अच्छा संतुलन बनाता है।

मैं फिर से "त्रुटि वापस/अतिरिक्त संदर्भ के साथ" भाग पर फिर से जाना चाहता हूं, क्योंकि मुझे लगता है कि त्रुटि को अनदेखा करना पहले से ही मौजूदा _ द्वारा कवर किया गया है।

मैं एक दो-शब्द कीवर्ड का प्रस्ताव कर रहा हूं जिसके बाद एक स्ट्रिंग (वैकल्पिक रूप से) हो सकती है।

@urandom आपके प्रस्ताव का पहला भाग सहमत है, कोई हमेशा इसके साथ शुरू कर सकता है और दूसरे संशोधन के लिए BubbleProcessor छोड़ सकता है। @object88 द्वारा उठाई गई चिंताएं वैध IMO हैं; मैंने हाल ही में ऐसी सलाहें देखी हैं जैसे "आपको http के डिफ़ॉल्ट क्लाइंट/परिवहन को अधिलेखित नहीं करना चाहिए", यह उनमें से एक और बन जाएगा।

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

अगर कोई चर्चा की गई समस्याओं की एक संगठित और सारांशित सूची को बनाए रखने के लिए अविश्वसनीय लेकिन महत्वपूर्ण कार्य करना चाहता है तो मैं भी उत्साहित हूं।

अगर @ianlancetaylor आपको नियुक्त करता है तो यह आप @josharian हो सकते हैं? :ब्लश: मुझे नहीं पता कि अन्य मुद्दों की योजना/चर्चा कैसे की जा रही है लेकिन शायद इस चर्चा को सिर्फ "सुझाव बॉक्स" के रूप में इस्तेमाल किया जा रहा है?

@KamyarM

@bcmills आप वहां सुझाए गए कोड को गिन सकते हैं। मुझे लगता है कि एक के बजाय कोड की 6 लाइनें हैं और शायद आपको इसके लिए कुछ कोड साइक्लोमैटिक जटिलता बिंदु मिलते हैं (आप लोग लिंटर का उपयोग करते हैं। सही?)।

चक्रीय जटिलता को छिपाने से इसे देखना कठिन हो जाता है लेकिन यह इसे दूर नहीं करता है (याद रखें strlen ?)। जिस तरह "छोटा" त्रुटि प्रबंधन करने से त्रुटि प्रबंधन अर्थशास्त्र को अनदेखा करना आसान हो जाता है - लेकिन देखना कठिन होता है।

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

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

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

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

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

मुझे @gburgessiv का प्रस्ताव भी पसंद है, हालांकि मैं स्वयं क्रिप्टिक ऑपरेटर का बहुत बड़ा प्रशंसक नहीं हूं (शायद कम से कम ? जैसे रस्ट में चुनें, हालांकि मुझे अभी भी लगता है कि यह गूढ़ है)। क्या यह अधिक पठनीय लगेगा:

func foo(r io.ReadCloser, callAfterClosing func() error, bs []byte) ([]byte, error) {
  // If r.Read fails, returns `nil, errors.New("reading from r: " + err.Error())`
  n := r.Read(bs) or returnErrorf("reading from r")
  bs = bs[:n]
  // If r.Close() fails, returns `nil, errors.New("closing r after reading [[bs's contents]]: " + err.Error())`
  r.Close() or returnErrorf("closing r after reading %q", string(bs))
  // Not that I advocate this inline-func approach, but...
  callAfterClosing() or func(err error) error { return errors.New("oh no!") }
  return bs, nil
}

और उम्मीद है कि उनके प्रस्ताव में errors पैकेज में कहीं उनके returnErrorf के समान फ़ंक्शन का डिफ़ॉल्ट कार्यान्वयन भी शामिल होगा। शायद errors.Returnf() ।

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

@ जोशेरियन , मैं संक्षेप में चर्चा को सारांशित करने का प्रयास करूंगा। यह पक्षपाती होगा, क्योंकि मेरे पास मिश्रण में एक प्रस्ताव है, और अधूरा है, क्योंकि मैं पूरे धागे को फिर से पढ़ने के लिए तैयार नहीं हूं।

हम जिस समस्या का समाधान करने का प्रयास कर रहे हैं, वह है गो एरर हैंडलिंग के कारण होने वाली दृश्य अव्यवस्था। यहां एक अच्छा उदाहरण है ( स्रोत ):

func (ds *GitDataSource) Fetch(from, to string) ([]string, error) {
    if err := createFolderIfNotExist(to); err != nil {
        return nil, err
    }
    if err := clearFolder(to); err != nil {
        return nil, err
    }
    if err := cloneRepo(to, from); err != nil {
        return nil, err
    }
    dirs, err := getContentFolders(to)
    if err != nil {
        return nil, err
    }
    return dirs, nil
}

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

ऐसे प्रस्ताव जो कोड को सरल बनाने का प्रयास करते हैं, कुछ समूहों में विभाजित होते हैं।

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

यहां कई प्रस्ताव एक डिफ़ॉल्ट कार्रवाई का चयन करते हैं, जैसे फ़ंक्शन (मूल प्रस्ताव) से लौटना या घबराना, और कुछ सिंटैक्स का सुझाव देना जो उस क्रिया को व्यक्त करना आसान बनाता है। मेरी राय में, वे सभी प्रस्ताव विफल हो जाते हैं, क्योंकि वे दूसरों की कीमत पर एक कार्रवाई का विशेषाधिकार देते हैं। मैं नियमित रूप से रिटर्न का उपयोग करता हूं, t.Fatal और log.Fatal त्रुटियों को संभालने के लिए, कभी-कभी सभी एक ही दिन में।

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

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

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

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

जिन लोगों के विचारों का यहाँ प्रतिनिधित्व नहीं है, उनसे क्षमा याचना।

मुझे ऐसा लग रहा है कि कोई मुझसे चीनी और जादू में अंतर के बारे में पूछेगा। (मैं खुद यह पूछ रहा हूं।)

चीनी एक छोटा सा वाक्यविन्यास है जो भाषा के नियमों को मौलिक रूप से बदले बिना कोड को छोटा करता है। लघु असाइनमेंट ऑपरेटर := चीनी है। तो सी का टर्नरी ऑपरेटर ?: ।

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

रेखा निश्चित रूप से धुंधली है।

ऐसा करने के लिए धन्यवाद, @jba। बहुत मददगार। केवल हाइलाइट्स को बाहर निकालने के लिए, अब तक पहचानी गई समस्याएं हैं:

गो त्रुटि प्रबंधन के कारण दृश्य अव्यवस्था

तथा

आतंक की उपस्थिति में त्रुटि-प्रबंधन बहुत मुश्किल हो सकता है

यदि कोई अन्य मौलिक रूप से भिन्न समस्याएं हैं (समाधान नहीं) जो @jba और मैं चूक गए हैं, तो कृपया (किसी को) झंकार करें। एफडब्ल्यूआईडब्ल्यू, मैं एर्गोनॉमिक्स, कोड क्लटर, साइक्लोमैटिक जटिलता, स्टटर, बॉयलरप्लेट इत्यादि को "विजुअल क्लटर" समस्या (या समस्याओं का समूह) के रूपों के रूप में मानता हूं।

@josharian क्या आप स्कोपिंग समस्याओं (https://github.com/golang/go/issues/21161#issuecomment-319277657) को "दृश्य अव्यवस्था" समस्या के एक प्रकार के रूप में या एक अलग मुद्दे पर विचार करना चाहते हैं?

@bcmills मेरे लिए अलग लगता है, क्योंकि यह सूक्ष्म शुद्धता के मुद्दों के बारे में है, जैसा कि सौंदर्यशास्त्र/एर्गोनॉमिक्स (या कोड बल्क से जुड़े अधिकांश शुद्धता मुद्दों पर) के विपरीत है। धन्यवाद! मेरी टिप्पणी संपादित करना चाहते हैं और इसके एक-पंक्ति सारांश में जोड़ना चाहते हैं?

मुझे ऐसा लग रहा है कि कोई मुझसे चीनी और जादू में अंतर के बारे में पूछेगा। (मैं खुद यह पूछ रहा हूं।)

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

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

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

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

इसके बारे में अच्छी बात यह है कि यह लगभग सभी विषयपरकता को प्रश्न से बाहर कर देता है।

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

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

उदाहरण के लिए, मैंने नियंत्रण प्रवाह में अतिरिक्त छलांग लगाने के बारे में कुछ शिकायतें देखी हैं। लेकिन मेरे लिए, बहुत ही मूल प्रस्ताव की भाषा में, अगर वे आम हैं तो मुझे फ़ंक्शन के भीतर आठ बार || &PathError{"chdir", dir, err} जोड़ने की आवश्यकता नहीं है। (मुझे पता है कि गो को कुछ अन्य भाषाओं की तरह बार-बार कोड से एलर्जी नहीं है, लेकिन फिर भी, बार-बार कोड डायवर्जेंस बग के लिए बहुत अधिक जोखिम में है।) लेकिन परिभाषा के अनुसार, अगर इस तरह की त्रुटि से निपटने के लिए कोई तंत्र है, तो कोड ऊपर से नीचे, बाएं से दाएं, बिना किसी छलांग के प्रवाहित नहीं हो सकता। आमतौर पर किसे अधिक महत्वपूर्ण माना जाता है? मुझे संदेह है कि लोगों द्वारा कोड पर निहित आवश्यकताओं की सावधानीपूर्वक जांच अन्य परस्पर-विरोधाभासी आवश्यकताओं को प्रकट करेगी।

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

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

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

मुझे यकीन नहीं है कि यह पार्सिंग/संकलन के मामले में कितना अच्छा काम करेगा, लेकिन ऐसा लगता है कि इसे एक कथन के रूप में व्याख्या करना काफी आसान होना चाहिए जहां '?' संगतता को तोड़े बिना देखा जाता है जहां यह नहीं देखा जाता है, इसलिए सोचा कि मैं इसे एक विकल्प के रूप में वहां फेंक दूंगा।

इसके अतिरिक्त त्रुटि प्रबंधन से परे इसके लिए अन्य उपयोग भी होंगे।

तो आप कुछ ऐसा कर सकते हैं:

func example1() error {
    err := doSomething()
    return err != nil ? err
    //more code
}

func example2() (*Mything, error) {
    err := doSomething()
    return err != nil ? nil, err
    //more code
}

हम इस तरह की चीजें भी कर सकते हैं जब हमारे पास कुछ साफ कोड होता है, यह मानते हुए कि हैंडलईर ने एक गलती लौटा दी है:

func example3() error {
    err := doSomething()
    return err !=nil ? handleErr(err)
    //more code
}

func example4() (*Mything, error) {
    err := doSomething()
    return err != nil ? nil, handleErr(err)
    //more code
}

शायद इसके बाद यह भी चलता है कि यदि आप चाहें तो आप इसे एक लाइनर तक कम कर पाएंगे:

func example5() error {
    return err := doSomething(); err !=nil ? handleErr(err)
    //more code
}

func example6() (*Mything, error) {
    return err := doSomething(); err !=nil ? nil, handleErr(err)
    //more code
}

@jba से पिछला लाने का उदाहरण संभावित रूप से इस तरह

func (ds *GitDataSource) Fetch(from, to string) ([]string, error) {

    return err := createFolderIfNotExist(to); err != nil ? nil, err
    return err := clearFolder(to); err != nil ? nil, err
    return err := cloneRepo(to, from); err != nil ? nil, err
    dirs, err := getContentFolders(to)

    return dirs, err
}

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

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

func (ds *GitDataSource) Fetch(from, to string) ([]string, error) {

    return? err := createFolderIfNotExist(to); err != nil ? nil, err
    return? err := clearFolder(to); err != nil ? nil, err
    return? err := cloneRepo(to, from); err != nil ? nil, err
    dirs, err := getContentFolders(to)

    return dirs, err
}

के बीच बहुत अंतर नहीं लगता है

return err != nil ? err

तथा

 if err != nil { return err }

साथ ही, कभी-कभी आप वापसी के अलावा कुछ और करना चाहेंगे, जैसे panic या log.Fatal कॉल करें।

मैं इस पर कताई कर रहा हूं क्योंकि मैंने पिछले हफ्ते एक प्रस्ताव रखा था, और मैं इस निष्कर्ष पर पहुंचा हूं कि मैं @thejerf से सहमत

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

1. त्रुटि को अनदेखा करना
2. असंशोधित त्रुटि लौटाना
3. संदर्भ के साथ त्रुटि लौटाना जोड़ा गया
4. पैनिकिंग (या प्रोग्राम को मारना)

प्रस्ताव तीन श्रेणियों में से एक में आते हैं:

1. त्रुटि प्रबंधन की try-catch-finally शैली पर वापस लौटें।
2. ऊपर सूचीबद्ध सभी 4 मामलों को संभालने के लिए नया सिंटैक्स/बिलिन जोड़ें
3. यह कहते हुए कि go कुछ मामलों को अच्छी तरह से संभालता है, और अन्य मामलों में मदद करने के लिए सिंटैक्स/बिलिन का प्रस्ताव करता है।

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

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

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

@ianlancetaylor , या कोई और मेरे से अधिक निकटता से परियोजना के साथ शामिल है, क्या आप एक "औपचारिक" (सभी एक टिप्पणी में, संगठित, और कुछ हद तक व्यापक लेकिन किसी भी तरह से बाध्यकारी नहीं) को जोड़ने में सहज महसूस करेंगे, जिसे पूरा करने की आवश्यकता है? हो सकता है कि अगर हम उन मानदंडों पर चर्चा करते हैं और प्रस्तावों को पूरा करने के लिए आवश्यक 4-6 बुलेट बिंदुओं को कम करते हैं, तो हम कुछ और संदर्भों के साथ चर्चा को फिर से बूट कर सकते हैं?

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

• 1 के लिए अच्छा समर्थन) किसी त्रुटि को अनदेखा करना; 2) असंशोधित त्रुटि लौटाना; 3) अतिरिक्त संदर्भ के साथ एक त्रुटि लपेटना।
• जबकि त्रुटि प्रबंधन कोड स्पष्ट होना चाहिए, यह फ़ंक्शन पर हावी नहीं होना चाहिए। गैर-त्रुटि प्रबंधन कोड को पढ़ना आसान होना चाहिए।
• मौजूदा गो 1 कोड को काम करना जारी रखना चाहिए, या कम से कम पूरी विश्वसनीयता के साथ गो 1 को नए दृष्टिकोण में यांत्रिक रूप से अनुवाद करना संभव होना चाहिए।
• नए दृष्टिकोण से प्रोग्रामर को त्रुटियों को सही ढंग से संभालने के लिए प्रोत्साहित करना चाहिए। आदर्श रूप से सही काम करना आसान होना चाहिए, चाहे किसी भी स्थिति में सही चीज कुछ भी हो।
• कोई भी नया दृष्टिकोण वर्तमान दृष्टिकोण की तुलना में छोटा और/या कम दोहराव वाला होना चाहिए, जबकि स्पष्ट रहना चाहिए।
• भाषा आज काम करती है, और हर बदलाव की कीमत चुकानी पड़ती है। परिवर्तन का लाभ स्पष्ट रूप से लागत के लायक होना चाहिए। यह सिर्फ धोना नहीं होना चाहिए, यह स्पष्ट रूप से बेहतर होना चाहिए।

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

मैंने इसे अपनी वास्तविक परियोजना से निकाला है और बाहरी रिलीज के लिए इसे साफ़ कर दिया है। (मुझे लगता है कि stdlib सबसे अच्छा स्रोत नहीं है, क्योंकि इसमें लॉगिंग चिंताएं गायब हैं, दूसरों के बीच ..)

func NewClient(...) (*Client, error) {
    listener, err := net.Listen("tcp4", listenAddr)
    if err != nil {
        return nil, err
    }
    defer func() {
        if err != nil {
            listener.Close()
        }
    }()

    conn, err := ConnectionManager{}.connect(server, tlsConfig)
    if err != nil {
        return nil, err
    }
    defer func() {
        if err != nil {
            conn.Close()
        }
    }()

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
        u, _ := url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort))
        forwardOut = forwarding.NewOut(u)
    }

    client := &Client{...}

    toServer := communicationProtocol.Wrap(conn)
    err = toServer.Send(&client.serverConfig)
    if err != nil {
        return nil, err
    }

    err = toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})
    if err != nil {
        return nil, err
    }

    session, err := communicationProtocol.FinalProtocol(conn)
    if err != nil {
        return nil, err
    }
    client.session = session

    return client, nil
}

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

अवलोकन:

1. यह सही कोड नहीं है; मैं बेयर एरर बहुत लौटाता हूं क्योंकि यह इतना आसान है, ठीक उसी तरह का कोड जिसमें हमें समस्या है। प्रस्तावों को संक्षिप्त रूप से और कितनी आसानी से वे इस कोड को ठीक करते हुए प्रदर्शित करते हैं, दोनों द्वारा स्कोर किया जाना चाहिए।
2. if forwardPort == 0 खंड _deliberately_ त्रुटियों के माध्यम से जारी है, और हाँ, यह वास्तविक व्यवहार है, न कि कुछ ऐसा जो मैंने इस उदाहरण के लिए जोड़ा है।
3. यह कोड या तो एक वैध, कनेक्टेड क्लाइंट देता है या यह एक त्रुटि देता है और कोई संसाधन लीक नहीं होता है, इसलिए .Close() (केवल फ़ंक्शन त्रुटियों के बाहर) के आसपास हैंडलिंग जानबूझकर है। नोट भी बंद करें से त्रुटियां गायब हो जाती हैं, जैसा कि वास्तविक गो में काफी विशिष्ट है।
4. पोर्ट नंबर कहीं और विवश है, इसलिए url.Parse विफल नहीं हो सकता (परीक्षा के द्वारा)।

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

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

try का उपयोग करना जहां try if != nil return के लिए सिर्फ एक शॉर्टकट है, कोड को 59 में से 6 लाइनों से कम कर देता है, जो लगभग 10% है।

func NewClient(...) (*Client, error) {
    listener, err := net.Listen("tcp4", listenAddr)
    try err

    defer func() {
        if err != nil {
            listener.Close()
        }
    }()

    conn, err := ConnectionManager{}.connect(server, tlsConfig)
    try err

    defer func() {
        if err != nil {
            conn.Close()
        }
    }()

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
        u, _ := url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort))
        forwardOut = forwarding.NewOut(u)
    }

    client := &Client{...}

    toServer := communicationProtocol.Wrap(conn)
    err = toServer.Send(&client.serverConfig)
    try err

    err = toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})
    try err

    session, err := communicationProtocol.FinalProtocol(conn)
    try err

    client.session = session

    return client, nil
}

विशेष रूप से, कई जगहों पर मैं try x() लिखना चाहता था, लेकिन मैं ऐसा नहीं कर सका क्योंकि मुझे डिफर्स को ठीक से काम करने के लिए सेट करने के लिए त्रुटि की आवश्यकता थी।

एक और। अगर हमारे पास try कुछ ऐसा है जो असाइनमेंट लाइनों पर हो सकता है, तो यह 47 लाइनों तक चला जाता है।

func NewClient(...) (*Client, error) {
    try listener, err := net.Listen("tcp4", listenAddr)

    defer func() {
        if err != nil {
            listener.Close()
        }
    }()

    try conn, err := ConnectionManager{}.connect(server, tlsConfig)

    defer func() {
        if err != nil {
            conn.Close()
        }
    }()

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
        u, _ := url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort))
        forwardOut = forwarding.NewOut(u)
    }

    client := &Client{...}

    toServer := communicationProtocol.Wrap(conn)
    try err = toServer.Send(&client.serverConfig)

    try err = toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})

    try session, err := communicationProtocol.FinalProtocol(conn)

    client.session = session

    return client, nil
}

import "github.com/pkg/errors"

func Func3() (T1, T2, error) {...}

type PathError {
    err Error
    x   T3
    y   T4
}

type MiscError {
    x   T5
    y   T6
    err Error
}


func Foo() (T1, T2, error) {
    // Old school
    a, b, err := Func(3)
    if err != nil {
        return nil
    }

    // Simplest form.
    // If last unhandled arg's type is same 
    // as last param of func,
    // then use anon variable,
    // check and return
    a, b := Func3()
    /*    
    a, b, err := Func3()
    if err != nil {
         return T1{}, T2{}, err
    }
    */

    // Simple wrapper
    // If wrappers 1st param TypeOf Error - then pass last and only unhandled arg from Func3() there
    a, b, errors.WithStack() := Func3() 
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, errors.WithStack(err)
    }
    */

    // Bit more complex wrapper
    a, b, errors.WithMessage("unable to get a and b") := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, errors.WithMessage(err, "unable to get a and b")
    }
    */

    // More complex wrapper
    // If wrappers 1nd param TypeOf is not Error - then pass last and only unhandled arg from Func3() as last
    a, b, fmt.Errorf("at %v Func3() return error %v", time.Now()) := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, fmt.Errorf("at %v Func3() return error %v", time.Now(), err)
    }
    */

    // Wrapping with error types
    a, b, &PathError{x,y} := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, &PathError{err, x, y}
    }
    */
    a, b, &MiscError{x,y} := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, &MiscError{x, y, err}
    }
    */

    return a, b, nil
}

थोड़ा जादू (-1 के लिए स्वतंत्र महसूस करें) लेकिन यांत्रिक अनुवाद का समर्थन करता है

यह वही है (कुछ हद तक अद्यतन) मेरा प्रस्ताव इस तरह दिखेगा:

func NewClient(...) (*Client, error) {
    defer annotateError("client couldn't be created")

    listener := pop net.Listen("tcp4", listenAddr)
    defer closeOnErr(listener)
    conn := pop ConnectionManager{}.connect(server, tlsConfig)
    defer closeOnErr(conn)

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
         forwardOut = forwarding.NewOut(pop url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort)))
    }

    client := &Client{listener: listener, conn: conn, forward: forwardOut}

    toServer := communicationProtocol.Wrap(conn)
    pop toServer.Send(&client.serverConfig)
    pop toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})
    session := pop communicationProtocol.FinalProtocol(conn)
    client.session = session

    return client, nil
}

func closeOnErr(c io.Closer) {
    if err := erroring(); err != nil {
        closeErr := c.Close()
        if err != nil {
            seterr(multierror.Append(err, closeErr))
        }
    }
}

func annotateError(annotation string) {
    if err := erroring(); err != nil {
        log.Printf("%s: %v", annotation, err)
        seterr(errwrap.Wrapf(annotation +": {{err}}", err))
    }
}

परिभाषाएँ:

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

erroring() को चल रहे आस्थगित फ़ंक्शन के लिए स्टैक के ऊपर जाने के रूप में परिभाषित किया गया है, और फिर पिछले स्टैक तत्व (इस मामले में न्यूक्लाइंट में फ़ंक्शन चल रहा है), वर्तमान में लौटाई गई त्रुटि के मान तक पहुंचने के लिए चालू। यदि फ़ंक्शन में ऐसा कोई पैरामीटर नहीं है, तो या तो घबराएं या शून्य लौटें (जो भी अधिक समझ में आता है)। यह त्रुटि मान pop से आना आवश्यक नहीं है; यह कुछ भी है जो लक्ष्य फ़ंक्शन से त्रुटि देता है।

seterr(error) आपको लौटाए जा रहे त्रुटि मान को बदलने की अनुमति देता है। यह तब किसी भी भविष्य के erroring() कॉल द्वारा देखी गई त्रुटि होगी, जैसा कि यहां दिखाया गया है वही डिफर-आधारित चेनिंग की अनुमति देता है जो अभी किया जा सकता है।

मैं यहाँ हैशिकॉर्प रैपिंग और मल्टीएरर का उपयोग कर रहा हूँ; इच्छानुसार अपने स्वयं के चतुर पैकेज डालें।

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

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

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

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

नुकसान में erroring , pop , और seterr कीवर्ड के रूप में दावा करना शामिल है, इन कार्यात्मकताओं के लिए defer ओवरहेड

यहाँ बहुत ही रोचक चर्चा है।

मैं त्रुटि चर को बाईं ओर रखना चाहूंगा ताकि कोई जादुई रूप से दिखने वाले चर पेश न किए जाएं। मूल प्रस्ताव की तरह मैं उसी लाइन पर त्रुटि सामग्री को संभालना चाहता हूं। मैं || -ऑपरेटर का उपयोग नहीं करता क्योंकि यह मेरे लिए "बहुत बूलियन" दिखता है और किसी भी तरह "वापसी" छुपाता है।

इसलिए मैं विस्तारित कीवर्ड "रिटर्न?" का उपयोग करके इसे और अधिक पठनीय बनाऊंगा। C# में कुछ स्थानों पर शॉर्टकट बनाने के लिए प्रश्न चिह्न का उपयोग किया जाता है। ई. जी. लिखने के बजाय:

if(foo != null)
{ foo.Bar(); }

आप बस लिख सकते हैं:
foo?.Bar();

तो गो 2 के लिए मैं इस समाधान का प्रस्ताव करना चाहूंगा:

func foobar() error {
    return fmt.Errorf("Some error happened")
}

// Implicitly return err (there must be exactly one error variable on the left side)
err := foobar() return?
// Explicitly return err
err := foobar() return? err
// Return extended error info
err := foobar() return? &PathError{"chdir", dir, err}
// Return tuple
err := foobar() return? -1, err
// Return result of function (e. g. for logging the error)
err := foobar() return? handleError(err)
// This doesn't compile as you ignore the error intentionally
foobar() return?

सिर्फ एक विचार:

फू, गलती: = myFunc ()
गलती!= शून्य? वापसी लपेटो (त्रुटि)

या

अगर गलती!= शून्य? वापसी लपेटो (त्रुटि)

यदि आप उसके चारों ओर कुछ घुंघराले ब्रेसिज़ लगाने को तैयार हैं, तो हमें कुछ भी बदलने की आवश्यकता नहीं है!

if err != nil { return wrap(err) }

आपके पास _all_ मनचाहा कस्टम हैंडलिंग (या बिल्कुल भी नहीं) हो सकता है, आपने सामान्य मामले से कोड की दो पंक्तियों को सहेजा है, यह 100% पीछे की ओर संगत है (क्योंकि भाषा में कोई बदलाव नहीं है), यह अधिक कॉम्पैक्ट है, और यह है आसान। यह इयान के कई gofmt टूलींग हो सकता है?

मैंने कार्लमजॉनसन के सुझाव को पढ़ने से पहले यह लिखा था, जो समान है ...

किसी त्रुटि से ठीक पहले # ।

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

@after(func (data string, err error) {
  if err != nil {
    log.Error("error", data, " - ", err)
  }
})
func alo() (string, error) {
  // this is the equivalent of
  // data, err := db.Find()
  // if err != nil { 
  //   return "", err 
  // }
  str, #err := db.Find()

  // ...

  #err = db.Create()

  // ...

  return str, nil
}

func alo2() ([]byte, []byte, error, error) {
  // this is the equivalent of
  // data, data2, err, errNotFound := db.Find()
  // if err != nil { 
  //   return nil, nil, err, nil
  // } else if errNotFound != nil {
  //   return nil, nil, nil, errNotFound
  // }
  data, data2, #err, #errNotFound := db.Find()

  // ...

  return data, data2, nil, nil
}

क्लीनर फिर:

func alo() (string, error) {
  str, err := db.Find()
  if err != nil {
    log.Error("error on find in database", err)
    return "", err
  }

  // ...

  if err := db.Create(); err != nil {
    log.Error("error on create", err)
    return "", err
  }

  // ...

  return str, nil
}

func alo2() ([]byte, []byte, error, error) {
  data, data2, err, errNotFound := db.Find()
  if err != nil { 
    return nil, nil, err, nil
  } else if errNotFound != nil {
    return nil, nil, nil, errNotFound
  }

  // ...

  return data, data2, nil, nil
}

कैसे की तरह एक स्विफ्ट के बारे में guard बयान के बजाय सिवाय guard...else यह guard...return :

file, err := os.Open("fails.txt")
guard err return &FooError{"Couldn't foo fails.txt", err}

guard os.Remove("fails.txt") return &FooError{"Couldn't remove fails.txt", err}

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

1. बूलियन संदर्भ में शून्य-सक्षम वस्तुओं का उपयोग करने की अनुमति दें, जहां nil false बराबर है, गैर- nil से true
2. && और || जैसे सिंगल-लाइन कंडीशनल स्टेटमेंट ऑपरेटरों का समर्थन करें

इसलिए

file, err := os.Open("fails.txt")
if err != nil {
    return &FooError{"Couldn't foo fails.txt", err}
}

बन सकता है

file, err := os.Open("fails.txt")
if err {
    return &FooError{"Couldn't foo fails.txt", err}
}

या उससे भी छोटा

file, err := os.Open("fails.txt")
err && return &FooError{"Couldn't foo fails.txt", err}

और, हम कर सकते हैं

i,ok := v.(int)
ok || return fmt.Errorf("not a number")

या शायद

i,ok := v.(int)
ok && s *= i

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

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

साथ ही, यह कुछ अन्य भाषाओं के अलावा "सत्यता" की पूरी श्रृंखला का समर्थन करने का प्रस्ताव नहीं है। ये सशर्त केवल शून्य/गैर-शून्य, या बूलियन का समर्थन करेंगे।

इन सशर्त ऑपरेटरों के लिए, यह एकल चर तक सीमित होने के लिए उपयुक्त हो सकता है और अभिव्यक्तियों का समर्थन नहीं कर सकता है। कुछ भी अधिक जटिल, या else क्लॉज के साथ मानक if ... संरचनाओं के साथ संभाला जाएगा।

सिर्फ एक पहिया का आविष्कार क्यों न करें और ज्ञात try..catch फॉर्म का उपयोग करें जैसा कि @mattn ने पहले कहा था? )

try {
    a := foo() // func foo(string, error)
    b := bar() // func bar(string, error)
} catch (err) {
    // handle error
}

ऐसा लगता है कि पकड़े गए त्रुटि स्रोत को अलग करने का कोई कारण नहीं है, क्योंकि यदि आपको वास्तव में इसकी आवश्यकता है तो आप हमेशा if err != nil बिना try..catch के पुराने रूप का उपयोग कर सकते हैं।

साथ ही, मैं वास्तव में इसके बारे में निश्चित नहीं हूं, लेकिन अगर इसे संभाला नहीं जाता है तो त्रुटि को "फेंकने" की क्षमता जोड़ सकती है?

func foo() (string, error) {
    f := bar() // similar to if err != nil { return "", err }
}

func baz() string {
    // Compilation error.
    // bar's error must be handled because baz() does not return error.
    return bar()
}

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

@creker हाँ, मैं

शायद कुछ ऐसा:

try {
    a ::= foo() // func foo(string, error)
    b ::= bar() // func bar(string, error)
} catch (err) {
    // handle error
}

या अन्य सुझाव जैसे try a := foo() ..?

@gobwas

जब मैं कैच ब्लॉक में उतरता हूं, तो मुझे कैसे पता चलेगा कि ट्राई ब्लॉक में कौन सा फंक्शन त्रुटि का कारण बना?

@urandom अगर आपको यह जानने की जरूरत है तो आप शायद if err != nil बिना try..catch ।

@ रॉबर्ट-वालिस: मैंने पहले धागे में स्विफ्ट के गार्ड स्टेटमेंट का उल्लेख किया

@pdk

बूलियन संदर्भ में शून्य-सक्षम वस्तुओं का उपयोग करने की अनुमति दें, जहां शून्य गलत के बराबर है, गैर-शून्य से सत्य है

मैं इसे ध्वज पैकेज का उपयोग करके बहुत सी बगों की ओर अग्रसर करता हूं जहां लोग if myflag { ... } लिखेंगे लेकिन इसका मतलब if *myflag { ... } लिखना है और यह संकलक द्वारा पकड़ा नहीं जाएगा।

कोशिश/पकड़ केवल तभी छोटा होता है जब आप कई चीजों को बैक-टू-बैक करने की कोशिश करते हैं, जो कि कम या ज्यादा सभी सहमत हैं, नियंत्रण प्रवाह के मुद्दों आदि के कारण खराब है।

एफडब्ल्यूआईडब्ल्यू, स्विफ्ट की कोशिश/पकड़ कम से कम दृश्य समस्या को हल करती है यह जानने की नहीं कि कौन से बयान फेंक सकते हैं:

do {
    let dragon = try summonDefaultDragon() 
    try dragon.breathFire()
} catch DragonError.dragonIsMissing {
    // ...
} catch DragonError.halatosis {
    // ...
}

@ रॉबर्ट-वालिस, आपके पास एक उदाहरण है:

file, err := os.Open("fails.txt")
guard err return &FooError{"Couldn't foo fails.txt", err}

guard os.Remove("fails.txt") return &FooError{"Couldn't remove fails.txt", err}

guard के पहले उपयोग पर, यह if err != nil { return &FooError{"Couldn't foo fails.txt", err}} जैसा बहुत भयानक लगता है, इसलिए मुझे यकीन नहीं है कि यह एक बड़ी जीत है।

दूसरे उपयोग पर, यह तुरंत स्पष्ट नहीं है कि err कहाँ से आता है। ऐसा लगता है कि यह वही है जो os.Open से लौटा है, जो मुझे लगता है कि आपका इरादा नहीं था? क्या यह अधिक सटीक होगा?

guard err = os.Remove("fails.txt") return &FooError{"Couldn't remove fails.txt", err}

किस मामले में ऐसा लगता है ...

if err = os.Remove("fails.txt"); err != nil { return &FooError{"Couldn't remove fails.txt", err}}

लेकिन इसमें अभी भी कम दृश्य अव्यवस्था है। if err = , ; err != nil { - भले ही यह एक लाइनर हो, इस तरह की एक साधारण चीज़ के लिए अभी भी बहुत कुछ चल रहा है

सहमत हैं कि कम अव्यवस्था है। लेकिन भाषा में जोड़ने की गारंटी देने के लिए काफी कम? मुझे यकीन नहीं है कि मैं वहां सहमत हूं।

मुझे लगता है कि जावा/सी#/... में ट्राइ-कैच ब्लॉक की पठनीयता बहुत अच्छी है क्योंकि आप त्रुटि प्रबंधन द्वारा बिना किसी रुकावट के "खुश पथ" अनुक्रम का अनुसरण कर सकते हैं। नकारात्मकता यह है कि आपके पास मूल रूप से एक छिपी हुई गोटो तंत्र है।

गो में मैं "खुश पथ" तर्क की निरंतरता को और अधिक दृश्यमान बनाने के लिए त्रुटि हैंडलर के बाद खाली लाइनें डालना शुरू करता हूं। तो इस नमूने में से golang.org (9 लाइन) से

record := new(Record)
err := datastore.Get(c, key, record) 
if err != nil {
    return &appError{err, "Record not found", 404}
}
err := viewTemplate.Execute(w, record)
if err != nil {
    return &appError{err, "Can't display record", 500}
}

मैं अक्सर ऐसा करता हूँ (11 पंक्तियाँ)

record := new(Record)

err := datastore.Get(c, key, record) 
if err != nil {
    return &appError{err, "Record not found", 404}
}

err := viewTemplate.Execute(w, record)
if err != nil {
    return &appError{err, "Can't display record", 500}
}

अब प्रस्ताव पर वापस, जैसा कि मैंने पहले ही कुछ इस तरह पोस्ट किया है, यह अच्छा होगा (3 पंक्तियाँ)

record := new(Record)
err := datastore.Get(c, key, record) return? &appError{err, "Record not found", 404}
err := viewTemplate.Execute(w, record) return? &appError{err, "Can't display record", 500}

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

सभी पक्षों से एक प्रश्न: क्या इस कोड को संकलित करना चाहिए?

func foobar() error {
    return fmt.Errorf("Some error")
}
func main() {
    foobar()
}

आईएमएचओ उपयोगकर्ता को यह कहने के लिए मजबूर होना चाहिए कि वह जानबूझकर त्रुटि को अनदेखा करता है:

func main() {
    _ := foobar()
}

@ianlancetaylor मूल पोस्ट के बिंदु 3 से संबंधित एक मिनी अनुभव रिपोर्ट अतिरिक्त प्रासंगिक जानकारी के साथ त्रुटि लौटाएं ।

गो के लिए एक flac लाइब्रेरी विकसित करते समय, हम @davecheney pkg/errors पैकेज (https://github.com/mewkiz/flac/issues/22) का उपयोग करके त्रुटियों में प्रासंगिक जानकारी जोड़ना चाहते थे। अधिक विशेष रूप से, हम त्रुटियों का उपयोग करके लौटाई गई त्रुटियों को लपेटते हैं। विथस्टैक जो स्टैक ट्रेस जानकारी के साथ त्रुटियों की व्याख्या करता है।

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

type withStack struct {
    error
    *stack
}

अब, मूल त्रुटि को पुनः प्राप्त करने के लिए, त्रुटियों का उपयोग करने की परंपरा है। io.EOF ।

पुस्तकालय का एक उपयोगकर्ता तब मूल त्रुटि की जांच के लिए errors.Cause का उपयोग करके https://github.com/mewkiz/flac/blob/0884ed715ef801ce2ce0c262d1e674fdda6c3d94/cmd/flac2wav/flac2wav.go#L78 की तर्ज पर कुछ लिख सकता है। मूल्य:

frame, err := stream.ParseNext()
if err != nil {
    if errors.Cause(err) == io.EOF {
        break
    }
    return errors.WithStack(err)
}

यह लगभग सभी मामलों में अच्छा काम करता है।

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

समस्या यह थी कि zeros.Read द्वारा लौटाई गई त्रुटि का अंतर्निहित प्रकार अब io.EOF के बजाय error.withStack है। इस प्रकार बाद में समस्याएँ पैदा हुईं जब हमने उस पाठक को io.Copy संयोजन में उपयोग किया, जो विशेष रूप से io.EOF लिए जाँच करता है, और errors.Cause करने के लिए एनोटेट की गई त्रुटि को "अनरैप" करना नहीं जानता है संदर्भित जानकारी। चूंकि हम मानक पुस्तकालय को अद्यतन नहीं कर सकते हैं, इसलिए समाधान यह था कि बिना व्याख्या की गई जानकारी के त्रुटि लौटा दी जाए (https://github.com/mewkiz/flac/commit/6805a34d854d57b12f72fd74304ac296fd0c07be)।

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

हमारे अनुभव से दूर यह रहा है कि हम भाग्यशाली थे, क्योंकि हमारे परीक्षण मामलों ने इसे पकड़ लिया। कंपाइलर ने कोई त्रुटि उत्पन्न नहीं की, क्योंकि zeros प्रकार अभी भी io.Reader इंटरफ़ेस को लागू करता है। हमने यह भी नहीं सोचा था कि हम एक समस्या का सामना करेंगे, क्योंकि जोड़ा गया त्रुटि एनोटेशन एक मशीन जनित पुनर्लेखन था, केवल त्रुटियों के लिए प्रासंगिक जानकारी जोड़ने से सामान्य स्थिति में कार्यक्रम के व्यवहार को प्रभावित नहीं करना चाहिए।

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

सहृदय निवेदन,
रोबिन

@mewmew , आइए इस मुद्दे को त्रुटि प्रबंधन के नियंत्रण प्रवाह पहलुओं के बारे में रखें। कैसे सबसे अच्छा रैप और अनरैप त्रुटियों पर कहीं और चर्चा की जानी चाहिए, क्योंकि यह प्रवाह को नियंत्रित करने के लिए काफी हद तक ऑर्थोगोनल है।

मैं आपके कोडबेस से परिचित नहीं हूं, और मुझे एहसास हुआ कि आपने कहा था कि यह एक स्वचालित रिफैक्टरिंग था, लेकिन आपको ईओएफ के साथ प्रासंगिक जानकारी शामिल करने की आवश्यकता क्यों थी? यद्यपि इसे टाइप सिस्टम द्वारा एक त्रुटि के रूप में माना जाता है, EOF वास्तव में एक सिग्नल मान से अधिक है, वास्तविक त्रुटि नहीं। विशेष रूप से io.Reader कार्यान्वयन में, यह अधिकांश समय अपेक्षित मूल्य है। यदि यह io.EOF नहीं होता तो केवल त्रुटि को लपेटने के लिए बेहतर समाधान नहीं होता?

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

मेरा मतलब है कि कोशिश-पकड़-फेंक अनिवार्य रूप से आतंक() और पुनर्प्राप्त() का वही व्यवहार नहीं है?

आह, अगर हम वास्तव में इस सड़क से नीचे जाने की कोशिश करना शुरू करने जा रहे हैं। हम ऐसा कुछ क्यों नहीं कर सकते

_, ? := foo()
x?, err? := bar()

या शायद कुछ ऐसा भी

_, err := foo(); return err?
x, err := bar(); return x? || err?
x, y, err := baz(); return (x? && y?) || err?

जहां ? if var != nil{ return var } के लिए एक शॉर्टहैंड उपनाम बन जाता है।

हम एक और विशेष बिलिन इंटरफ़ेस भी परिभाषित कर सकते हैं जो विधि से संतुष्ट है

func ?() bool //looks funky but avoids breakage.

जिसका उपयोग हम अनिवार्य रूप से नए और बेहतर सशर्त ऑपरेटर के डिफ़ॉल्ट व्यवहार को ओवरराइड करने के लिए कर सकते हैं।

@mortdeus

मुझे लगता है कि मैं सहमत हूं।
यदि समस्या हैप्पी पथ प्रस्तुत करने का एक अच्छा तरीका है, तो आईडीई के लिए एक प्लगइन शॉर्टकट के साथ if err != nil { return [...] } प्रत्येक उदाहरण को फोल्ड/प्रकट कर सकता है?

मुझे लगता है कि अब हर हिस्सा महत्वपूर्ण है। err != nil महत्वपूर्ण है। return ... महत्वपूर्ण है।
लिखने में थोड़ी परेशानी होती है, लेकिन इसे लिखना पड़ता है। और क्या यह वास्तव में लोगों को धीमा कर देता है? क्या समय लगता है त्रुटि के बारे में सोच रहा है और क्या वापस करना है, इसे लिखना नहीं है।

मुझे ऐसे प्रस्ताव में अधिक दिलचस्पी होगी जो err चर के दायरे को सीमित करने की अनुमति देता है।

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

मैं नहीं देखता कि यह कैसे काम कर सकता है:

एक्स, वाई, गलती: = बाज़ (); वापसी ( x? && y? ) || err?

जहां ? अगर var == nil {रिटर्न var} के लिए शॉर्टहैंड उपनाम बन जाता है।

एक्स, वाई, गलती: = बाज़ (); वापसी ( if x == nil{ return x} && if y== nil{ return y} ) || if err == nil{ return err}

एक्स, वाई, गलती: = बाज़ (); वापसी (एक्स? && वाई?) || गलती?

हो जाता है

एक्स, वाई, गलती: = बाज़ ();
अगर ((x != nil && y !=nil) || गलती !=nil)){
वापसी एक्स, वाई, त्रुटि
}

जब आप एक्स देखते हैं? && वाई? || गलती? आप सोच रहे होंगे "क्या x और y मान्य हैं? गलती के बारे में क्या?"

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

मेरा सुझाव है कि गो संस्करण 2 में डिफ़ॉल्ट त्रुटि प्रबंधन जोड़ें।

यदि उपयोगकर्ता त्रुटि को संभालता नहीं है, तो संकलक त्रुटि देता है यदि यह शून्य नहीं है, तो यदि उपयोगकर्ता लिखता है:

func Func() error {
    func1()
    func2()
    return nil
}

func func1() error {
    ...
}

func func2() error {
    ...
}

इसे संकलित करें:

func Func() error {
    err := func1()
    if err != nil {
        return err
    }

    err = func2()
    if err != nil {
        return err
    }

    return nil
}

func func1() error {
    ...
}

func func2() error {
    ...
}

यदि उपयोगकर्ता गलती को संभालता है या _ का उपयोग करके इसे अनदेखा करता है, तो कंपाइलर कुछ नहीं करेगा:

_ = func1()

या

err := func1()

एकाधिक वापसी मूल्यों के लिए, यह समान है:

func Func() (*YYY, error) {
    ch, x := func1()
    return yyy, nil
}

func func1() (chan int, *XXX, error) {
    ...
}

कंपाइलर में बदल जाएगा:

func Func() (*YYY, error) {
    ch, x, err := func1()
    if err != nil {
        return nil, err
    }

    return yyy, nil
}

func func1() (chan int, *XXX, error) {
    ...
}

यदि Func () के हस्ताक्षर त्रुटि नहीं लौटाते हैं, लेकिन कॉल फ़ंक्शन जो त्रुटि लौटाते हैं, तो संकलक त्रुटि की रिपोर्ट करेगा: "कृपया Func () में अपनी त्रुटि को संभालें"
तब उपयोगकर्ता केवल Func() में गलती लॉग कर सकता है

और यदि उपयोगकर्ता गलती से कुछ जानकारी लपेटना चाहता है:

func Func() (*YYY, error) {
    ch, x := func1() ? Wrap(err, "xxxxx", ch, "abc", ...)
    return yyy, nil
}

या

func Func() (*YYY, error) {
    ch, x := func1() ? errors.New("another error")
    return yyy, nil
}

फायदा है,

1. प्रोग्राम उस बिंदु पर विफल हो जाता है जहां त्रुटि होती है, उपयोगकर्ता त्रुटि को पूरी तरह से अनदेखा नहीं कर सकता है।
2. विशेष रूप से कोड की पंक्तियों को कम कर सकते हैं।

यह इतना आसान नहीं है क्योंकि गो में कई रिटर्न मान हो सकते हैं और भाषा को यह निर्दिष्ट नहीं करना चाहिए कि डेवलपर को स्पष्ट रूप से पता चल रहा है कि क्या हो रहा है।

मेरा मानना ​​​​है कि असाइनमेंट सिंटैक्स में एरर हैंडलिंग डालने से समस्या की जड़ हल नहीं होती है, जो कि "एरर हैंडलिंग रिपीटेटिव है"।

कोड की कई पंक्तियों (जहां ऐसा करना समझ में आता है) के बाद if (err != nil) { return nil } (या समान) का उपयोग करना डीआरवाई (स्वयं को दोहराएं) प्रिंसिपल के खिलाफ जाता है। मेरा मानना ​​है कि इसलिए हमें यह पसंद नहीं है।

try ... catch साथ भी समस्याएं हैं। आपको उसी फ़ंक्शन में त्रुटि को स्पष्ट रूप से संभालने की आवश्यकता नहीं है जहां यह होता है। मेरा मानना ​​है कि यह एक उल्लेखनीय कारण है कि हमें try...catch ।

मैं नहीं मानता कि ये परस्पर अनन्य हैं; हमारे पास try...catch बिना throws एक प्रकार का हो सकता है।

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

मैं यही प्रस्ताव करता हूं:

• लौटाई गई त्रुटि के लिए प्लेसहोल्डर के रूप में ? का उपयोग करना, जहां _ का उपयोग इसे अनदेखा करने के लिए किया जाएगा
• catch बजाय जैसा कि नीचे दिए गए मेरे उदाहरण में है, error? का उपयोग इसके बजाय पूर्ण पश्च संगतता के लिए किया जा सकता है

^ अगर मेरी धारणा है कि ये पीछे की ओर संगत हैं, गलत है तो कृपया इसे कॉल करें।

func example() {
    {
        // The following line will invoke the catch block
        data, ? := foopkg.buyIt()
        // The next two lines handle an error differently
        otherData, err := foopkg.useIt()
        if err != nil {
            // Here we eliminated deeper indentation
            otherData, ? = foopkg.breakIt()
        }
        if data == "" || otherData == "" {
        }
    } catch (err) {
        return errors.Label("fix it", err)
        // Aside: why not add Label() to the error package?
    }
}

मैंने इसके खिलाफ एक तर्क के बारे में सोचा: यदि आप इसे इस तरह लिखते हैं, तो उस catch ब्लॉक को बदलने से कोड पर गहरे दायरे में अनपेक्षित प्रभाव पड़ सकता है। यह वही समस्या है जो हमें try...catch ।

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

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

2 संपादित करें: पागल विचार: शायद catch ब्लॉक सिर्फ नियंत्रण प्रवाह को प्रभावित नहीं करेगा ... यह सचमुच त्रुटि के बाद लाइन में catch { ... } के अंदर कोड को कॉपी और पेस्ट करने जैसा होगा ? एड (बिल्कुल नहीं - इसका अभी भी अपना दायरा होगा)। यह अजीब लगता है क्योंकि हममें से कोई भी इसका अभ्यस्त नहीं है, इसलिए catch निश्चित रूप से कीवर्ड नहीं होना चाहिए यदि इसे इस तरह से किया जाता है, लेकिन अन्यथा... क्यों नहीं?

@mewmew , आइए इस मुद्दे को त्रुटि प्रबंधन के नियंत्रण प्रवाह पहलुओं के बारे में रखें। कैसे सबसे अच्छा रैप और अनरैप त्रुटियों पर कहीं और चर्चा की जानी चाहिए, क्योंकि यह प्रवाह को नियंत्रित करने के लिए काफी हद तक ऑर्थोगोनल है।

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

@jba क्या आप विशेष रूप से त्रुटियों के लिए प्रासंगिक जानकारी को लपेटने/

मैं आपके कोडबेस से परिचित नहीं हूं, और मुझे एहसास हुआ कि आपने कहा था कि यह एक स्वचालित रिफैक्टरिंग था, लेकिन आपको ईओएफ के साथ प्रासंगिक जानकारी शामिल करने की आवश्यकता क्यों थी? यद्यपि इसे टाइप सिस्टम द्वारा एक त्रुटि के रूप में माना जाता है, EOF वास्तव में एक सिग्नल मान से अधिक है, वास्तविक त्रुटि नहीं। विशेष रूप से io.Reader कार्यान्वयन में, यह अधिकांश समय अपेक्षित मूल्य है। अगर यह io.EOF नहीं होता तो केवल त्रुटि को लपेटने के लिए बेहतर फिक्स नहीं होता?

@DeedleFake मैं थोड़ा विस्तार कर सकता हूं, लेकिन विषय पर बने रहने के लिए उपरोक्त मुद्दे में त्रुटियों के लिए प्रासंगिक जानकारी को लपेटने/खोलने के लिए समर्पित किया जाएगा।

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

मैं क्या चाहता हूं कि कुछ प्रवर्तन गलती से त्रुटि वापसी मूल्य को अनदेखा न करें लेकिन कम से कम लागू करें
_ := returnsError()

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

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

कुछ टाइपिंग को बचाने के लिए एक और सुझाव निहित है nil बूलियन के साथ की तरह जाँच:

err := returnsError()
if err { return err }

या और भी

if err := returnsError(); err { return err }

यह सभी सूचक प्रकार के कारणों के साथ काम करेगा।

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

कम पठनीय कोड और अधिक जटिल वाक्यविन्यास।

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

एक त्रुटि को बुदबुदाते हुए और हर चीज के लिए शून्य-मान लौटाने का पैटर्न

19642 इसे आसान बना देगा।

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

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

https://gist.github.com/KernelDeimos/384aabd36e1789efe8cbce3c17ffa390

इस सार में एक से अधिक विचार हैं, इसलिए मुझे आशा है कि उन पर एक दूसरे से अलग चर्चा की जा सकती है

एक पल के लिए इस विचार को अलग रखते हुए कि यहां प्रस्ताव को स्पष्ट रूप से त्रुटि प्रबंधन के बारे में होना चाहिए, क्या होगा यदि गो ने collect कथन की तरह कुछ पेश किया?

एक collect स्टेटमेंट फॉर्म का होगा collect [IDENT] [BLOCK STMT] , जहां ident मुझे nil -एबल टाइप का इन-स्कोप वैरिएबल होना चाहिए। collect कथन के भीतर, एक विशेष चर _! चर के लिए एक उपनाम के रूप में उपलब्ध है जिसे एकत्र किया जा रहा है। _! उपयोग कहीं भी नहीं किया जा सकता है, लेकिन असाइनमेंट के रूप में, _ । जब भी _! को असाइन किया जाता है, तो एक अंतर्निहित nil चेक किया जाता है, और यदि _! शून्य नहीं है, तो ब्लॉक निष्पादन बंद कर देता है और शेष कोड के साथ जारी रहता है।

सैद्धांतिक रूप से, यह कुछ इस तरह दिखेगा:

func TryComplexOperation() (*Result, error) {
    var result *Result
    var err error

    collect err {
        intermediate1, _! := Step1()
        intermediate2, _! := Step2(intermediate1, "something")
        // assign to result from the outer scope
        result, _! = Step3(intermediate2, 12)
    }
    return result, err
}

जो के बराबर है

func TryComplexOperation() (*Result, error) {
    var result *Result
    var err error

    {
        var intermediate1 SomeType
        intermediate1, err = Step1()
        if err != nil { goto collectEnd }

        var intermediate2 SomeOtherType
        intermediate2, err = Step2(intermediate1, "something")
        if err != nil { goto collectEnd }

        result, err = Step3(intermediate2, 12)
        // if err != nil { goto collectEnd }, but since we're at the end already we can omit this
    }

collectEnd:
    return result, err
}

कुछ अच्छी अन्य चीजें इस तरह की एक सिंटैक्स सुविधा सक्षम करेगी:

// try several approaches for acquiring a value
func GetSomething() (s *Something) {
    collect s {
        _! = fetchOrNil1()
        _! = fetchOrNil2()
        _! = new(Something)
    }
    return s
}

नई सिंटैक्स सुविधाओं की आवश्यकता है:

1. कीवर्ड collect
2. विशेष पहचान _! (मैंने इसके साथ पार्सर में खेला है, इस मैच को किसी और चीज को तोड़े बिना पहचान के रूप में बनाना मुश्किल नहीं है)

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

• 1 के लिए अच्छा समर्थन) किसी त्रुटि को अनदेखा करना; 3) अतिरिक्त संदर्भ के साथ एक त्रुटि लपेटना।

जांचें, क्योंकि यह वही रहता है (ज्यादातर)

• जबकि त्रुटि प्रबंधन कोड स्पष्ट होना चाहिए, यह फ़ंक्शन पर हावी नहीं होना चाहिए।