त्रुटियों को सही तरीके से कैसे संभालें: मौन हमेशा अच्छा नहीं होता है

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

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

हम आपको याद दिलाते हैं: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रोमो कोड का उपयोग करके किसी भी स्किलबॉक्स कोर्स के लिए पंजीकरण करते समय 10,000 रूबल की छूट।

स्किलबॉक्स अनुशंसा करता है: ऑन-लाइन शैक्षिक पाठ्यक्रम "प्रोफेशन जावा-डेवलपर" ।

यह हमेशा कंधे से काट लेने के लायक नहीं है

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

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

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

वापसी नल या अन्य जादू नंबर

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

उनके साथ, आपका कोड ऐसे ब्लॉक से भरा होगा जो एप्लिकेशन लॉजिक को अस्पष्ट बना देगा:

return_value = possibly_return_a_magic_value() if return_value < 0: handle_error() else: do_something() other_return_value = possibly_nullable_value() if other_return_value is None: handle_null_value() else: do_some_other_thing() 

ठीक है, या सरल, लेकिन यह भी बुरा है:

 var item = returnSomethingWhichCouldBeNull(); var result = item?.Property?.MaybeExists; if (result.HasValue) { DoSomething(); } 

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

त्रुटि कोड

अनावश्यक कोड जटिलता को जोड़ने पर अशक्त और अन्य समान मूल्यों के साथ यह एक ही समस्या है।

उदाहरण के लिए, आप एक त्रुटि कोड वापस करने के लिए इस निर्माण का उपयोग कर सकते हैं:

 int errorCode; var result = getSomething(out errorCode); if (errorCode != 0) { doSomethingWithResult(result); } 

परिणाम निम्नानुसार प्रदर्शित किया जा सकता है:

 public class Result<T> { public T Item { get; set; } // At least "ErrorCode" is an enum public ErrorCode ErrorCode { get; set; } = ErrorCode.None; public IsError { get { return ErrorCode != ErrorCode.None; } } } public class UsingResultConstruct { ... var result = GetResult(); if (result.IsError) { switch (result.ErrorCode) { case ErrorCode.NetworkError: HandleNetworkError(); break; case ErrorCode.UserError: HandleUserError(); break; default: HandleUnknownError(); break; } } ActuallyDoSomethingWithResult(result); ... } 

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

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

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

यदि यह पहली बार काम नहीं करता है, तो फिर से प्रयास करें

जारी रखने से पहले, यह जोर देने योग्य है कि "मौन" प्रोग्राम विफलता खराब है। सबसे अप्रत्याशित समय पर एक अप्रत्याशित समस्या हो सकती है - उदाहरण के लिए, सप्ताहांत पर, जब आप जल्दी से सब कुछ ठीक नहीं कर सकते।



यदि आप स्वच्छ कोड पढ़ते हैं, तो आप सबसे अधिक संभावना है कि सिर्फ एक अपवाद क्यों नहीं फेंकें? यदि नहीं, तो सबसे अधिक संभावना है कि आप सोचते हैं कि अपवाद बुराई की जड़ है। मैं भी ऐसा सोचता था, लेकिन अब थोड़ा अलग सोचता हूं।

एक दिलचस्प बिंदु, कम से कम मेरे लिए, यह है कि C # में नई पद्धति के लिए डिफ़ॉल्ट कार्यान्वयन एक NotImplementedException को उठाना है, जबकि पायथन में नई विधि के लिए डिफ़ॉल्ट "पास" है।

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

लेकिन इस पर एक नज़र डालें:

 public MyDataObject UpdateSomething(MyDataObject toUpdate) { if (_dbConnection == null) { throw new DbConnectionError(); } try { var newVersion = _dbConnection.Update(toUpdate); if (newVersion == null) { return null; } MyDataObject result = new MyDataObject(newVersion); return result; } catch (DbConnectionClosedException dbcc) { throw new DbConnectionError(); } catch (MyDataObjectUnhappyException dou) { throw new MalformedDataException(); } catch (Exception ex) { throw new UnknownErrorException(); } } 

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

ऐसा होने से रोकने के लिए, मैं आपको इसे ध्यान में रखने की सलाह देता हूं:

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

 def my_function(): try: do_this() do_that() except: something_bad_happened() finally: cleanup_resource() 

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

 public MyDataObject UpdateSomething(MyDataObject toUpdate) { try { var newVersion = _dbConnection.Update(toUpdate); MyDataObject result = new MyDataObject(newVersion); return result; } catch (DbConnectionClosedException dbcc) { HandleDbConnectionClosed(); throw new UpdateMyDataObjectException(); } catch (MyDataObjectUnhappyException dou) { RollbackVersion(); throw new UpdateMyDataObjectException(); } catch (Exception ex) { throw new UpdateMyDataObjectException(); } } 

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

 def my_api(): try: item = get_something_from_the_db() new_version = do_something_to_item(item) return new_version except Exception as ex: handle_high_level_exception(ex) 

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

स्किलबॉक्स अनुशंसा करता है:

• व्यावहारिक पाठ्यक्रम "मोबाइल डेवलपर प्रो" ।
• ऑनलाइन पाठ्यक्रम "सी # खरोंच से डेवलपर । "
• दो वर्षीय व्यावहारिक पाठ्यक्रम "मैं एक प्रो वेब डेवलपर हूं । "