Errorx क्या है और यह कैसे उपयोगी है

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

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

मिस्टेक इन गो

एररएक्सएक्स के बारे में कहानी पर जाने से पहले, कुछ स्पष्टीकरण किया जाना चाहिए। अंत में, बग्स में क्या गलत है?

type error interface { Error() string }

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

 func New(text string) error { return &errorString{text} }

यदि हम याद करते हैं कि किसी भाषा में त्रुटियों की कोई विशेष स्थिति नहीं है और सामान्य वस्तुएं हैं, तो सवाल उठता है: उनके साथ काम करने की ख़ासियत क्या है?

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

क्या गलत है?

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

Error: duplicate key

यहां, पहली समस्या तुरंत स्पष्ट हो जाती है: यदि आप इस उद्देश्य पर ध्यान नहीं देते हैं, तो किसी भी तरह से बड़ी प्रणाली में यह समझना लगभग असंभव है कि क्या गलत हुआ, केवल प्रारंभिक संदेश से। इस पोस्ट में विवरण का अभाव है और समस्या का व्यापक संदर्भ है। यह एक प्रोग्रामर की गलती है, लेकिन यह अक्सर इसे उपेक्षित करने के लिए भी होता है। नियंत्रण ग्राफ की "सकारात्मक" शाखाओं के लिए समर्पित कोड हमेशा अभ्यास में अधिक ध्यान देने योग्य होता है और निष्पादन या बाहरी समस्याओं के व्यवधान से जुड़े "नकारात्मक" कोड की तुलना में परीक्षण द्वारा बेहतर कवर किया जाता है। कितनी बार if err != nil {return err} मंत्र गलत हो if err != nil {return err} गो कार्यक्रमों में दोहराया जाता है, इससे ओवरसाइट की संभावना और भी अधिक हो जाती है।

एक छोटे विषयांतर के रूप में, इस उदाहरण पर विचार करें:

 func (m *Manager) ApplyToUsers(action func(User) (*Data, error), ids []UserID) error { users, err := m.LoadUsers(ids) if err != nil { return err } var actionData []*Data for _, user := range users { data, err := action(user) if err != nil { return err } ok, err := m.validateData(data) if err != nil { return nil } if !ok { log.Error("Validation failed for %v", data) continue } actionData = append(actionData, data) } return m.Apply(actionData) }

आपने कितनी तेजी से इस कोड में त्रुटि देखी? लेकिन यह कम से कम एक बार किया गया था, शायद किसी भी गो प्रोग्रामर द्वारा। संकेत: if err != nil { return nil } गलत है तो अभिव्यक्ति में त्रुटि if err != nil { return nil } ।

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

मान लें कि एक कड़वा अनुभव प्रोग्रामर उस त्रुटि के लिए पहले से संदर्भ जोड़ना चाहता है जो वापस आती है। ऐसा करने का भोला तरीका कुछ इस प्रकार है:

 func InsertUser(u *User) error { err := usersTable.Insert(u) if err != nil { return errors.New(fmt.Sprintf("failed to insert user %s: %v", u.Name, err) } return nil }

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

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

 var ErrDuplicateKey = errors.New("duplicate key") func (t *Table) Insert(entity interface{}) error { // returns ErrDuplicateKey if a unique constraint is violated by insert } func IsDuplicateKeyError(err error) bool { return err == ErrDuplicateKey }

अब IsDuplicateKeyError() चेक नष्ट हो गया है, हालांकि उस समय जब हमने अपने पाठ को त्रुटि में जोड़ा था, तब हमारा इसका शब्दार्थ बदलने का कोई इरादा नहीं था। यह बदले में, इस चेक पर निर्भर कोड को तोड़ देगा:

 func RegisterUser(u *User) error { err := InsertUser(u) if db.IsDuplicateKeyError(err) { // find existing user, handle conflict } else { return err } }

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

अब त्रुटि प्रसंस्करण के स्थान पर आपको यह जानना होगा कि सही कारण Cause()
इस ज्ञान को बाहरी पुस्तकालयों को पढ़ाने का कोई तरीका नहीं है, और उनमें लिखे सहायक कार्य बेकार रहेंगे
हमारा कार्यान्वयन त्रुटि (या यदि यह नहीं है) के तत्काल कारण Cause() वापस Cause() उम्मीद कर सकता है, जबकि अन्य पुस्तकालय में कार्यान्वयन गैर-शून्य मूल कारण को वापस करने की विधि की अपेक्षा करेगा; मानक साधनों की कमी या आम तौर पर स्वीकृत अनुबंध बहुत अप्रिय आश्चर्य का खतरा है

हालांकि, इस आंशिक समाधान का उपयोग कई त्रुटि पुस्तकालयों में किया जाता है, जिसमें कुछ हद तक, हमारा भी शामिल है। इस दृष्टिकोण को लोकप्रिय बनाने के लिए गो 2 में योजनाएं हैं - यदि ऐसा होता है, तो ऊपर वर्णित समस्याओं से निपटना आसान होगा।

Errorx

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

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

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

मुख्य पुस्तकालय सुविधाओं द्वारा टीएल; डीआर:

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

परिचय

यदि हम त्रुटि का उपयोग करके ऊपर दिए गए उदाहरण का विश्लेषण करते हैं, तो हमें निम्नलिखित मिलते हैं:

 var ( DBErrors = errorx.NewNamespace("db") ErrDuplicateKey = DBErrors.NewType("duplicate_key") ) func (t *Table) Insert(entity interface{}) error { // ... return ErrDuplicateKey.New("violated constraint %s", details) } func IsDuplicateKeyError(err error) bool { return errorx.IsOfType(err, ErrDuplicateKey) }

 func InsertUser(u *User) error { err := usersTable.Insert(u) if err != nil { return errorx.Decorate(err, "failed to insert user %s", u.Name) } return nil }

IsDuplicateKeyError() का उपयोग कर कॉलर कोड नहीं बदलेगा।

इस उदाहरण में क्या बदलाव आया है?

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

यह हमेशा इस तरह की एक योजना का पालन करने के लिए आवश्यक नहीं है:

त्रुटि का प्रकार हमेशा अद्वितीय से बहुत दूर है: एक ही प्रकार का उपयोग कई स्थानों पर किया जा सकता है
यदि वांछित है, तो स्टैक ट्रेस संग्रह को अक्षम किया जा सकता है, और आप हर बार एक नई त्रुटि नहीं बना सकते हैं, लेकिन मूल उदाहरण में उसी को लौटा सकते हैं; ये तथाकथित प्रहरी त्रुटि हैं, और हम उनके उपयोग की अनुशंसा नहीं करते हैं, लेकिन यह उपयोगी हो सकता है यदि त्रुटि कोड में केवल मार्कर के रूप में उपयोग की जाती है, और आप ऑब्जेक्ट बनाने पर बचत करना चाहते हैं
errorx.IsOfType(err, ErrDuplicateKey) बनाने का एक तरीका है। errorx.IsOfType(err, ErrDuplicateKey) स्टॉप काम करना बंद कर देता है, यदि आप मूल कारणों के शब्दार्थ को errorx.IsOfType(err, ErrDuplicateKey) आँखों से छिपाना चाहते हैं
सटीक प्रकार की तुलना करने के अलावा स्वयं की जाँच करने के अन्य तरीके भी हैं

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

प्रकार

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

 AuthErrors = errorx.NewNamespace("auth") ErrInvalidToken = AuthErrors.NewType("invalid_token")

 return ErrInvalidToken.NewWithNoMessage()

त्रुटि संदेश में auth.invalid_token . auth.invalid_token होगा। त्रुटि घोषणा अलग दिख सकती है:

 ErrInvalidToken = AuthErrors.NewType("invalid_token").ApplyModifiers(errorx.TypeModifierOmitStackTrace)

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

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

त्रुटि निर्माण

 return MyType.New("fail")

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

 return errorx.IllegalArgument.New("negative value %d", value)

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

 return errorx.Decorate(err, "failed to upload '%s' to '%s'", filename, location)

त्रुटि में जोड़ा गया पाठ लॉग में दिखाई देगा, लेकिन यह मूल त्रुटि के प्रकार की जांच करने के लिए चोट नहीं पहुंचाएगा।

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

 return service.ErrBadRequest.Wrap(err, "failed to load user data")

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

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

 return errorx.EnhanceStackTrace(err, "operation fail")

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

गोडोक में अधिक जानकारी है और डेकोरेटमनी जैसी अतिरिक्त सुविधाओं का भी वर्णन किया गया है।

हैंडलिंग में त्रुटि

त्रुटि से निपटने के लिए नीचे आने पर सर्वश्रेष्ठ:

 log.Error("Error: %+v", err)

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

 if errorx.IsOfType(err, MyType) { /* handle */ }

यह जाँच दोनों प्रकार के MyType और उसके बच्चे के प्रकारों की एक त्रुटि पर सफल होगी, और यह errorx.Decorate() लिए प्रतिरोधी है। यहां, हालांकि, त्रुटि के प्रकार पर प्रत्यक्ष निर्भरता है, जो पैकेज के भीतर काफी सामान्य है, लेकिन इसके बाहर इस्तेमाल होने पर अप्रिय हो सकता है। कुछ मामलों में, ऐसी त्रुटि का प्रकार एक स्थिर बाहरी एपीआई का हिस्सा है, और कभी-कभी हम इस चेक को एक संपत्ति की जांच के साथ बदलना चाहते हैं, और सटीक प्रकार की त्रुटि नहीं।

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

 func IsTemporary(err error) bool { return HasTrait(err, Temporary()) }

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

 return errorx.IgnoreWithTrait(err, errorx.NotFound())

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

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

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

त्रुटि के बाहर

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

संगतता के मुद्दे

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

हालाँकि, कुछ चीजें की गई हैं ताकि अन्य मौजूदा समाधानों के साथ संघर्ष न हो।

यदि वर्तमान में स्टैक ट्रेस के साथ त्रुटि प्रिंट करने के लिए '%+v' प्रारूप '%+v' उपयोग किया जाता है। यह गो पारिस्थितिकी तंत्र में वास्तविक तथ्य है और इसे गो 2 के मसौदे के डिजाइन में भी शामिल किया गया है।

Cause() error errorx , , , Causer, errorx Wrap().

, Go 2, . .

, errorx Go 1. , Go 2, . , , errorx.

Check-handle , errorx , a Unwrap() error Wrap() errorx (.. , , Wrap ), . , , .

design draft Go 2, errorx.Is() errorx.As() , errors .

निष्कर्ष

, , , - , . , API : , , . 1.0 , Joom. , - .

: https://github.com/joomcode/errorx

, !

एररएक्स - गो में त्रुटियों के साथ काम करने के लिए पुस्तकालय