ऐसा असाधारण जाना

गो 2 में नई त्रुटि से निपटने के डिजाइन के ड्राफ्ट हाल ही में प्रकाशित हुए हैं। यह बहुत ही मनभावन है कि भाषा एक जगह नहीं खड़ी होती है - यह विकसित होती है और हर साल प्रेटियर बढ़ती है।

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

और तुरंत मैं एक बहुत महत्वपूर्ण और बिल्कुल गंभीर बयान देना चाहता हूं।
यह निर्णय प्रकृति में विशेष रूप से मनोरंजक और शैक्षणिक है।
मेरा मतलब सिर्फ 4 मज़े से है। यह आम तौर पर सच्चाई में एक सबूत की अवधारणा है। मैंने चेतावनी दी :)

तो क्या हुआ

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

हमने ऐसे कोड जनरेटर को गो-रॉ पर सेट किया है। वह मानक go/ast मॉड्यूल की मदद से इसे प्राप्त करता है, कुछ करता है नहीं चालाक रूपांतरण, परिणाम फ़ाइल के आगे लिखा है, प्रत्यय जोड़कर _jex.go । परिणामी फ़ाइलें काम करने के लिए एक छोटे क्रम चाहते हैं।

इस सरल तरीके से, हम अपवादों को गो में जोड़ते हैं।

हम उपयोग करते हैं

हम जनरेटर को फ़ाइल से कनेक्ट करते हैं, हेडर में ( package से पहले) हम लिखते हैं

 //+build jex //go:generate jex 

यदि आप अब कमांड go generate -tags jex चलाते go generate -tags jex , तो jex यूटिलिटी निष्पादित की जाएगी। वह os.Getenv("GOFILE") से फ़ाइल का नाम लेता है, इसे खाता है, इसे पचाता है और {file}_jex.go लिखता है। हेडर में नवजात फ़ाइल पहले से ही //+build !jex हैडर में (टैग उल्टा है), इसलिए go build , और इसके साथ कम्पार्टमेंट में अन्य कमांड, जैसे go test या go install , केवल नई , सही फाइलों को ध्यान में रखें। लेपोटा ...

अब डॉट-आयात github.com/anjensan/jex ।
हाँ, जबकि एक बिंदु के माध्यम से आयात अनिवार्य है। भविष्य में इसे उसी तरह छोड़ने की योजना है।

 import . "github.com/anjensan/jex" 

महान, अब आप कोड में THROW कार्यों TRY , THROW , EX कॉल सम्मिलित कर सकते हैं। इस सब के लिए, कोड वाक्यविन्यास रूप से मान्य है, और यहां तक ​​कि एक असंसाधित रूप में भी संकलन करता है (यह सिर्फ काम नहीं करता है), इसलिए ऑटो-पूर्णता उपलब्ध है और लिंटर वास्तव में कसम नहीं खाते हैं। संपादकों को इन कार्यों के लिए प्रलेखन भी दिखाया जाएगा, अगर केवल उनके पास एक था।

एक अपवाद फेंक दें

 THROW(errors.New("error name")) 

अपवाद को पकड़ो

 if TRY() { //   } else { fmt.Println(EX()) } 

एक अनाम फ़ंक्शन हुड के तहत उत्पन्न होता है। और इसमें defer । और इसका एक और कार्य है। और इसे recover ... खैर, अभी भी return और defer से निपटने के लिए थोड़ा सा जादू-टोना है।

और हाँ, वैसे, वे समर्थित हैं!

इसके अलावा, एक विशेष मैक्रो चर ERR । यदि आप इसमें कोई त्रुटि देते हैं, तो एक अपवाद फेंक दिया जाता है। ऐसे कार्यों को कॉल करना आसान है जो अभी भी पुराने तरीके से एक error लौटाते हैं

 file, ERR := os.Open(filename) 

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

उदाहरण

यहाँ सही, मुहावरेदार गो कोड का उदाहरण दिया गया है

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

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

 func CopyFile_(src, dst string) { defer ex.Logf("copy %s %s", src, dst) r, ERR := os.Open(src) defer r.Close() w, ERR := os.Create(dst) if TRY() { ERR := io.Copy(w, r) ERR := w.Close() } else { w.Close() os.Remove(dst) THROW() } } 

लेकिन उदाहरण के लिए, निम्नलिखित कार्यक्रम

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

के रूप में फिर से लिखा जा सकता है

 func main() { if TRY() { hex, ERR := ioutil.ReadAll(os.Stdin) data, ERR := parseHexdump(string(hex)) os.Stdout.Write(data) } else { log.Fatal(EX()) } } 

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

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

के रूप में फिर से लिखा जा सकता है

 func printSum_(a, b string) { x, ERR := strconv.Atoi(a) y, ERR := strconv.Atoi(b) fmt.Println("result:", x + y) } 

या यहां तक ​​कि

 func printSum_(a, b string) { fmt.Println("result:", must.Int_(strconv.Atoi(a)) + must.Int_(strconv.Atoi(b))) } 

अपवाद

नीचे की रेखा error उदाहरण पर एक सरल आवरण संरचना है।

 type exception struct { //  ,   err error //  ^W , ,    log []interface{} //      ,    suppress []*exception } 

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

और यहाँ एक अपवाद श्रृंखला का एक उदाहरण है

 func one_() { THROW(errors.New("one")) } func two_() { THROW(errors.New("two") } func three() { if TRY() { one_() } else { two_() } } 

यहां हम शांति से अपवाद को संभालते हैं, जैसे कि अचानक बैम ... और अपवाद two फेंक दिया जाता है। तो, स्रोत one suppress से इसे suppress क्षेत्र में संलग्न one । कुछ भी नहीं खो जाएगा, सब कुछ लॉग में जाएगा। इसलिए, बहुत लोकप्रिय fmt.Errorf("blabla: %v", err) पैटर्न fmt.Errorf("blabla: %v", err) का उपयोग करके सीधे संदेश पाठ में त्रुटियों की पूरी श्रृंखला को धकेलने की कोई विशेष आवश्यकता नहीं है। हालांकि, कोई भी, निश्चित रूप से यहां इसके उपयोग को प्रतिबंधित नहीं करता है, यदि आप वास्तव में चाहते हैं।

जब पकड़ना भूल गया

आह, एक और बहुत महत्वपूर्ण बिंदु। पठनीयता बढ़ाने के लिए, एक अतिरिक्त जांच है: यदि कोई फ़ंक्शन अपवाद को फेंक सकता है, तो उसका नाम _ साथ समाप्त होना चाहिए। एक जानबूझकर टेढ़ा नाम जो प्रोग्रामर को बताएगा "प्रिय महोदय, यहां आपके कार्यक्रम में कुछ गलत हो सकता है, कृपया सावधान और मेहनती रहें!"

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

टिप्पणी जाँच //jex:nocheck । यह, वैसे, एक अनाम फ़ंक्शन से अपवादों को फेंकने का एकमात्र तरीका है।

बेशक, यह सभी समस्याओं के लिए रामबाण नहीं है। चेकर इससे चूक जाएगा

 func bad_() { THROW(errors.New("ups")) } func worse() { f := bad_ f() } 

दूसरी ओर, यह गलत err declared and not used लिए मानक जांच से बहुत खराब err declared and not used , जिसे दरकिनार करना बहुत आसान है।

 func worse() { a, err := foo() if err != nil { return err } b, err := bar() //  ,    ok... go vet, ? } 

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

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

ढेर के बारे में

अक्सर डेवलपर्स, डिबगिंग को सरल बनाने के लिए, कस्टम error कार्यान्वयन के लिए एक स्टैक ट्रेस को चिपकाते हैं। इसके लिए कई लोकप्रिय पुस्तकालय भी हैं। लेकिन, सौभाग्य से, अपवादों के साथ, गो की एक दिलचस्प विशेषता के कारण इसे किसी भी अतिरिक्त कार्रवाई की आवश्यकता नहीं होती है - आतंक के दौरान, कोड के ढेर संदर्भ में defer ब्लॉकों defer निष्पादित किया जाता है जो आतंक को फेंक देता है। इसलिए यहाँ

 func foo_() { THROW(errors.New("ups")) } func bar() { if TRY() { foo_() } else { debug.PrintStack() } } 

एक पूर्ण-स्टैक ट्रेस ट्रेस होगा, थोड़ी सी क्रिया (मैं फ़ाइल नाम काट देता हूं)

  runtime/debug.Stack runtime/debug.PrintStack main.bar.func2 github.com/anjensan/jex/runtime.TryCatch.func1 panic main.foo_ main.bar.func1 github.com/anjensan/jex/runtime.TryCatch main.bar main.main 

स्टैक ट्रेस को फॉर्मेट करने / प्रिंट करने, सरोगेट कार्यों को ध्यान में रखते हुए, उन्हें पठनीयता के लिए छिपाने के लिए अपने स्वयं के सहायक बनाने के लिए चोट नहीं पहुंचती है। मुझे लगता है कि एक अच्छा विचार है, में लिखा है।

या आप स्टैक को पकड़ सकते हैं और ex.Log() का उपयोग करके इसे अपवाद में संलग्न कर सकते हैं। फिर, इस तरह के अपवाद को किसी अन्य हॉरिन में स्थानांतरित करने की अनुमति दी जाती है - स्ट्रेक्त्रेस खो नहीं जाते हैं।

 func foobar_() { e := make(chan error, 1) go func() { defer close(e) if TRY() { checkZero_() } else { EX().Log(debug.Stack()) //   e <- EX().Wrap() //     } }() ex.Must_(<-e) //  ,  ,  } 

दुर्भाग्य से

एह ... बेशक, ऐसा कुछ बेहतर लगेगा

  try { throw io.EOF, "some comment" } catch e { fmt.Printf("exception: %v", e) } 

लेकिन अफसोस, आह, गो की वाक्य रचना गैर-एक्स्टेंसिबल है।
[विचारपूर्वक] हालांकि, शायद, यह बेहतर के लिए है ...

किसी भी मामले में, आपको बिगाड़ना होगा। वैकल्पिक विचारों में से एक बनाना था

  TRY; { THROW(io.EOF, "some comment") }; CATCH; { fmt.Printf("exception: %v", EX) } 

लेकिन इस तरह के कोड go fmt बाद गूंगा दिखता है। और कंपाइलर शपथ लेता है जब वह दोनों शाखाओं में return है। if-TRY साथ ऐसी कोई समस्या नहीं है।

यह जरूरी होगा कि ERR मैक्रो को MUST फंक्शन (सिर्फ इससे बेहतर) से बदला जाए। लिखने के क्रम में

  return MUST(strconv.Atoi(a)) + MUST(strconv.Atoi(b)) 

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

हुड के नीचे

सभी संसाधित फ़ाइलों में एक नया आयात जोड़ा जाता है।

  import _jex "github.com/anjensan/jex/runtime" 

panic(_jex.NewException(...)) कॉल THROW panic(_jex.NewException(...)) THROW बदल दिया जाता है। EX() स्थानीय चर के नाम से भी बदला जाता है जिसमें पकड़ा गया अपवाद होता है।

लेकिन if TRY() {..} else {..} संसाधित किया जाता है तो थोड़ा और अधिक जटिल है। सबसे पहले, सभी return और defer लिए विशेष प्रसंस्करण होता है। तब संसाधित किया जाता है अगर शाखाओं को गुमनाम कार्यों में रखा जाता है। और फिर ये फ़ंक्शन _jex.TryCatch(..) को पास कर _jex.TryCatch(..) जाते हैं। यहाँ है

 func test(a int) (int, string) { fmt.Println("before") if TRY() { if a == 0 { THROW(errors.New("a == 0")) } defer fmt.Printf("a = %d\n", a) return a + 1, "ok" } else { fmt.Println("fail") } return 0, "hmm" } 

कुछ इस तरह से बदल जाता है (मैंने //line टिप्पणियों को हटा दिया):

 func test(a int) (_jex_r0 int, _jex_r1 string) { var _jex_ret bool fmt.Println("before") var _jex_md2502 _jex.MultiDefer defer _jex_md2502.Run() _jex.TryCatch(func() { if a == 0 { panic(_jex.NewException(errors.New("a == 0"))) } { _f, _p0, _p1 := fmt.Printf, "a = %d\n", a _jex_md2502.Defer(func() { _f(_p0, _p1) }) } _jex_ret, _jex_r0, _jex_r1 = true, a+1, "ok" return }, func(_jex_ex _jex.Exception) { defer _jex.Suppress(_jex_ex) fmt.Println("fail") }) if _jex_ret { return } return 0, "hmm" } 

एक बहुत, सुंदर नहीं है, लेकिन यह काम करता है। ठीक है, सब नहीं और हमेशा नहीं। उदाहरण के लिए, आप TRY के अंदर defer-recover नहीं कर सकते, क्योंकि फंक्शन कॉल अतिरिक्त लैम्ब्डा में बदल जाता है।

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

कोशिश

जिज्ञासा से बाहर, मैंने एक छोटा बेंचमार्क लिखा।

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

 ~ > cat /proc/cpuinfo | grep 'model name' | head -1 model name : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz ~ > go version go version go1.11 linux/amd64 ~ > go test -bench=. github.com/anjensan/jex/demo goos: linux goarch: amd64 pkg: github.com/anjensan/jex/demo BenchmarkNoErrors/_____10/exception-8 10000000 236 ns/op BenchmarkNoErrors/_____10/return_err-8 5000000 255 ns/op BenchmarkNoErrors/_____10/fmt.errorf-8 5000000 287 ns/op BenchmarkNoErrors/____100/exception-8 500000 3119 ns/op BenchmarkNoErrors/____100/return_err-8 500000 3194 ns/op BenchmarkNoErrors/____100/fmt.errorf-8 500000 3533 ns/op BenchmarkNoErrors/___1000/exception-8 30000 42356 ns/op BenchmarkNoErrors/___1000/return_err-8 30000 42204 ns/op BenchmarkNoErrors/___1000/fmt.errorf-8 30000 44465 ns/op BenchmarkNoErrors/__10000/exception-8 3000 525864 ns/op BenchmarkNoErrors/__10000/return_err-8 3000 524781 ns/op BenchmarkNoErrors/__10000/fmt.errorf-8 3000 561256 ns/op BenchmarkNoErrors/_100000/exception-8 200 6309181 ns/op BenchmarkNoErrors/_100000/return_err-8 200 6335135 ns/op BenchmarkNoErrors/_100000/fmt.errorf-8 200 6687197 ns/op BenchmarkNoErrors/1000000/exception-8 20 76274341 ns/op BenchmarkNoErrors/1000000/return_err-8 20 77806506 ns/op BenchmarkNoErrors/1000000/fmt.errorf-8 20 78019041 ns/op BenchmarkOneError/_____10/exception-8 2000000 712 ns/op BenchmarkOneError/_____10/return_err-8 5000000 268 ns/op BenchmarkOneError/_____10/fmt.errorf-8 2000000 799 ns/op BenchmarkOneError/____100/exception-8 500000 2296 ns/op BenchmarkOneError/____100/return_err-8 1000000 1809 ns/op BenchmarkOneError/____100/fmt.errorf-8 500000 3529 ns/op BenchmarkOneError/___1000/exception-8 100000 21168 ns/op BenchmarkOneError/___1000/return_err-8 100000 20747 ns/op BenchmarkOneError/___1000/fmt.errorf-8 50000 24560 ns/op BenchmarkOneError/__10000/exception-8 10000 242077 ns/op BenchmarkOneError/__10000/return_err-8 5000 242376 ns/op BenchmarkOneError/__10000/fmt.errorf-8 5000 251043 ns/op BenchmarkOneError/_100000/exception-8 500 2753692 ns/op BenchmarkOneError/_100000/return_err-8 500 2824116 ns/op BenchmarkOneError/_100000/fmt.errorf-8 500 2845701 ns/op BenchmarkOneError/1000000/exception-8 50 33452819 ns/op BenchmarkOneError/1000000/return_err-8 50 33374000 ns/op BenchmarkOneError/1000000/fmt.errorf-8 50 33705994 ns/op PASS ok github.com/anjensan/jex/demo 64.008s 

यदि त्रुटि को फेंक नहीं दिया गया है (कोड स्थिर और प्रबलित कंक्रीट है), तो अपवाद फेंकने की गारंटी लगभग fmt.Errorf और fmt.Errorf return err करने के लिए तुलनीय है। कभी-कभी थोड़ा तेज। लेकिन अगर त्रुटि को फेंक दिया गया था, तो अपवाद दूसरे स्थान पर जाते हैं। लेकिन यह सब "उपयोगी कार्य / त्रुटि" और स्टैक की गहराई के अनुपात पर निर्भर करता है। छोटे स्लाइस के लिए, return err गैप से आगे जाता है, मध्यम और बड़े स्लाइस के लिए, अपवाद पहले से ही मैन्युअल फॉरवर्डिंग के बराबर हैं।

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

एक परीक्षण के रूप में, मैंने अपवादों के लिए एक वास्तविक gosh लाइब्रेरी माइग्रेट किया ।

  default: THROW(fmt.Errorf("unsupported type %T", value)) 

 func rpcParams2XML(rpc interface{}) (string, error) { var err error buffer := "<params>" for i := 0; i < reflect.ValueOf(rpc).Elem().NumField(); i++ { var xml string buffer += "<param>" xml, err = rpc2XML(reflect.ValueOf(rpc).Elem().Field(i).Interface()) buffer += xml buffer += "</param>" } buffer += "</params>" return buffer, err } 

 func rpcParams2XML_(rpc interface{}) string { buffer := "<params>" for i := 0; i < reflect.ValueOf(rpc).Elem().NumField(); i++ { buffer += "<param>" buffer += rpc2XML_(reflect.ValueOf(rpc).Elem().Field(i).Interface()) buffer += "</param>" } buffer += "</params>" return buffer } 

 xmlstr, _ = rpcResponse2XML(response) 

 xmlstr = rpcResponse2XML_(response) 

 func DecodeClientResponse(r io.Reader, reply interface{}) error { rawxml, err := ioutil.ReadAll(r) if err != nil { return FaultSystemError } return xml2RPC(string(rawxml), reply) } 

 func DecodeClientResponse_(r io.Reader, reply interface{}) { var rawxml []byte if TRY() { rawxml, ERR = ioutil.ReadAll(r) } else { THROW(FaultSystemError) } xml2RPC_(string(rawxml), reply) } 

 func errorReporter(t testing.TB) func(error) { return func(e error) { t.Log(string(debug.Stack())) t.Fatal(e) } } func TestRPC2XMLConverter_(t *testing.T) { defer ex.Catch(errorReporter(t)) // ... xml := rpcRequest2XML_("Some.Method", req) } 

 func fault2XML(fault Fault) string { buffer := "<methodResponse><fault>" xml, _ := rpc2XML(fault) buffer += xml buffer += "</fault></methodResponse>" return buffer } 

 func fault2XML(fault Fault) string { buffer := "<methodResponse><fault>" if TRY() { buffer += rpc2XML_(fault) } else { fmt.Printf("ERR: %v", EX()) buffer += "<nil/>" } buffer += "</fault></methodResponse>" return buffer } 

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

एक निष्कर्ष के बजाय

इस लेख को लिखते समय, कोई भी गोफर घायल नहीं हुआ था।

गोफ़र-शराबी http://migranov.ru की तस्वीर के लिए धन्यवाद

मैं "प्रोग्रामिंग" और "असामान्य प्रोग्रामिंग" हब के बीच चयन नहीं कर सका।
एक बहुत ही मुश्किल विकल्प, दोनों में जोड़ा गया।