कोड विश्वसनीयता और NullReferenceException

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

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

यह अच्छा है कि हम प्रोग्रामर हैं, इंजीनियर नहीं हैं, और हम बहुत अधिक अनुमानित वस्तुओं के साथ काम कर रहे हैं। न केवल परमाणु स्कैनर का अभी तक आविष्कार नहीं हुआ है, बल्कि हम भौतिकी के सभी नियमों को भी नहीं जानते हैं। मुझे लगता है कि भौतिक करघे से सॉफ्टवेयर सिस्टम के बीच अंतर। सॉफ्टवेयर सिस्टम में ऐसे तत्व शामिल होते हैं जिनके व्यवहार की सैद्धांतिक रूप से भविष्यवाणी की जा सकती है। इसके अलावा, उनका व्यवहार समय पर निर्भर नहीं करता है - कार्यक्रम नहीं पहनते हैं।

इस उदाहरण पर विचार करें। .Net फ्रेमवर्क में, एक स्ट्रिंग ऑब्जेक्ट में एक विकल्प विधि है:

public string Substring(int startIndex) 

यह विधि एक स्ट्रिंग में एक स्ट्रिंग देती है, स्थिति startIndex पर शुरू होती है और स्ट्रिंग के अंत में समाप्त होती है। मान लें कि हमें एक ऐसी विधि की आवश्यकता है जो फ़ाइल नाम के अंतिम तीन वर्णों को लौटाए, और हमने निम्नलिखित कोड लिखा:

  static string Extension(string name) { return name.Substring(name.Length-3); } 

क्या यह कोड अच्छा है? हां, वह वही करता है जो आवश्यक है - अंतिम तीन वर्ण लौटाता है। और यह ठीक काम करता है, लेकिन जब तक लंबाई में तीन अक्षरों से कम एक फ़ाइल नाम नहीं आता है। और हम सबसे inopportune क्षण में ArgumentOutOfRangeException प्रकार का एक अपवाद प्राप्त करेंगे।

क्या हुआ? और जो हुआ वह यह है कि सबस्ट्रिंग विधि में एक गुंजाइश है और इसका उल्लंघन किया गया था। StartIndex तर्क मान [0, लंबाई ] सीमा में ले जा सकता है जहां लंबाई स्ट्रिंग की लंबाई है। यदि हम दो-आयामी समन्वय प्रणाली लेते हैं, जहां एक्स-अक्ष स्ट्रिंग की लंबाई है, और वाई-अक्ष प्रारंभिक सूचकांक है, तो हमें ऊपरी दाहिने तिमाही में एक त्रिकोणीय क्षेत्र मिलता है, जो अनंत तक जाता है। अब हम उन मानों के समुच्चय को चित्रित करेंगे जो हमारे कार्यान्वयन में सबस्ट्रिंग विधि में पारित किए जा सकते हैं। इस सेट का वर्णन समीकरण startIndex = लंबाई - 3. लाइन के सामान्य समीकरण द्वारा किया जाता है। लंबाई के साथ = 0 startIndex = -3, लंबाई के साथ = 3 startIndex = 0. अब प्रोग्राम क्रैश का कारण ग्राफ पर स्पष्ट रूप से दिखाया गया है: संभव इनपुट मानों की सीमा विधि परिभाषा के दायरे से परे जाती है।

हमें एक गलती मिली। इसे कैसे ठीक करें? यह इस बात पर निर्भर करता है कि हम क्या प्राप्त करना चाहते हैं, अर्थात् इस एक्सटेंशन विधि की आवश्यकताओं पर। सबस्ट्रिंग को कॉल करने से पहले आप एक शर्त डाल सकते हैं

  If(name.Length < 3) return String.Empty; 

या विधि को फिर से लिखें:

  static string Extension(string name) { int index = name.Length - 3; if (index < 0) index = 0; return name.Substring(index); } 

इन कार्यान्वयनों का व्यवहार अलग-अलग होता है, लेकिन दोनों ही मामलों में सभी संभावित तर्क मूल्य, सबस्ट्रिंग विधि के दायरे में आते हैं।

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

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

  static ProductDto Translate(ProductEntity e) { return new ProductDto() { Name = e.Name, Code = e.Code, Description = e.Description }; } 

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

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

 if (e == null) return null; 

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

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

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

यह दूसरा प्रश्न उठाता है: डीबी ब्लॉक में प्रक्रिया क्या होनी चाहिए यदि पारित पहचानकर्ता के साथ ऑब्जेक्ट डेटाबेस में मौजूद नहीं है? क्या यह अशक्त हो जाना चाहिए? नहीं, और इस कारण से।

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

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

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

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

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

इस प्रकार, यदि हम चाहते हैं कि अनुवाद विधि दोनों संदर्भों में मज़बूती से काम करे, तो हमें पंक्ति को जोड़कर इसका दायरा यथासंभव विस्तृत करना चाहिए

 if (e == null) return null; 

विधि की शुरुआत के लिए। वास्तव में, पहले संदर्भ में, डेटा एक्सेस स्तर शून्य नहीं लौट सकता है, और दूसरे में, नल पूरी तरह से वैध मूल्य है।

सामान्य स्थिति में, जब यह ज्ञात नहीं होता है कि अन्य संदर्भों में किस विधि का उपयोग किया जा सकता है, तो इसकी परिभाषा का दायरा यथासंभव विस्तृत किया जाना चाहिए।

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

जारी रखा जाए।