गो त्रुटि सामग्री बढ़ाना - github.com/ztrue/tracerr

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

चूंकि मुझे यकीन है कि कोई भी इससे पीड़ित नहीं था, इसलिए मैंने एक पैकेज बनाया जो यह कर सकता है:



→ गिटहब

सभी वह है:

1. त्रुटियों के लिए स्टैक ट्रेस जोड़ता है।
2. स्टैक ट्रेस और स्रोत टुकड़े प्रदर्शित करता है जहां यह त्रुटि हुई (स्रोत की उपस्थिति में, निश्चित रूप से)।

स्टैक ट्रेस जोड़ना

स्टैक ट्रेस के साथ बग बनाने के कई तरीके हैं:

//   err := tracerr.New("some error") //   Errorf,    ,   fmt.Errorf err := tracerr.Errorf("some error %d", num) //    ,    err = tracerr.Wrap(err) 

जब त्रुटि को फिर से लपेटा जाता है, तो स्टैक ट्रेस समान रहेगा और ओवरराइट नहीं किया जाएगा, यह सुविधाजनक है यदि यह ज्ञात नहीं है कि त्रुटि पहले से ही स्टैक ट्रेस है या नहीं।

कोड कुछ इस तरह दिख सकता है:

 func decodeFile(path string, data interface{}) error { b, err := ioutil.ReadFile(path) if err != nil { return tracerr.Wrap(err) } err = json.Unmarshal(b, data) //  err = nil,   nil return tracerr.Wrap(err) } 

स्टैक ट्रेस डिस्प्ले

100500 के माध्यम से त्रुटि के बाद if err != nil { return err } main() या (जहां यह संसाधित होता है) में अपनी मातृभूमि पर लौटता है, सबसे अधिक संभावना है कि आप इसे प्रदर्शित या गिरवी रखना चाहेंगे।
इसके लिए कई विकल्प हैं: सभी प्रिंट (प्रिंट पाठ) या स्प्रिंट (पाठ पाठ) के रूप में काम करते हैं:

1) प्रदर्शन त्रुटि पाठ और स्टैक ट्रेस:

 tracerr.Print(err) 

2) त्रुटि पाठ, स्टैक ट्रेस और स्रोत टुकड़ा (डिफ़ॉल्ट रूप से 6 लाइनें) प्रदर्शित करें:

 tracerr.PrintSource(err) 

3) वही, लेकिन रंग में, आमतौर पर अधिक जानकारीपूर्ण:

 tracerr.PrintSourceColor(err) 

4) आप एक पैरामीटर के रूप में पास कर सकते हैं कि कोड की कितनी लाइनें प्रदर्शित करनी हैं:

 tracerr.PrintSource(err, 9) tracerr.PrintSourceColor(err, 9) 

5) या 2 वैकल्पिक मापदंडों को पास करें, कितने पहले और कितने बाद लाइन को प्रदर्शित करने की त्रुटि के साथ:

 tracerr.PrintSource(err, 5, 2) tracerr.PrintSourceColor(err, 5, 2) 

सवाल

मुझे पहले से ही कुछ प्रतिक्रिया मिली है, इसलिए मैं पहले से ही पूछे गए कुछ प्रश्नों के उत्तर देने की अनुमति देता हूं।

प्रश्न: क्या यह केवल डिबग के लिए उपयुक्त है? डिबगर है।
ए: यह न केवल डिबगिंग के लिए उपयुक्त है, स्टैक ट्रेस के बारे में जानकारी के साथ त्रुटियों को लॉग करना संभव है, और यहां तक ​​कि स्रोत कोड के टुकड़े के साथ, ठेस पर, जैसा कि मेरे अनुभव में, यह इन त्रुटियों का विश्लेषण करते हुए तब सरल हो जाएगा।

प्रश्न: एक सुपर पैकेज pkg / त्रुटियाँ हैं, इसका उपयोग क्यों नहीं करते?
एक: हाँ, मैंने खुद इसका पूरी तरह से उपयोग किया है और मुझे खुशी है, लेकिन यह इन कारणों से मुझे पसंद नहीं आया:
1) स्रोत के साथ एक स्टैक ट्रेस को प्रदर्शित करने का कोई आसान तरीका नहीं है।
2) जब त्रुटि फिर से लपेटी जाती है (उदाहरण के लिए, एक स्तर अधिक), तो स्टैक ट्रेस को कम जानकारी वाले लोगों द्वारा अधिलेखित कर दिया जाता है।
3) प्रत्येक मोड़ के साथ अतिरिक्त त्रुटि पाठ भेजना अनिवार्य है, जो मुझे कोड लिखते / पढ़ते समय कुछ ओवरहेड लगता है।

प्रश्न: जाने में, त्रुटियाँ अपवाद नहीं हैं और आप ऐसा बिल्कुल नहीं कर सकते।
A: मैं मानता हूं, Go में त्रुटियां कोई अपवाद नहीं हैं। यदि आप हजारों को if err != nil { return err } से संसाधित करना पसंद करते हैं if err != nil { return err } किसी तरह से if err != nil { return err } - यह आपकी पसंद है, बिल्कुल आप केवल उन त्रुटियों को लपेट सकते हैं जिन्हें आप अपवाद के रूप में संभालते हैं।

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

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