C # 8.0 और स्थैतिक विश्लेषण में अशक्त संदर्भ प्रकार

यह कोई रहस्य नहीं है कि Microsoft काफी समय से C # भाषा के 8-वें संस्करण पर काम कर रहा है। नया भाषा संस्करण (C # 8.0) विज़ुअल स्टूडियो 2019 की हालिया रिलीज़ में पहले से ही उपलब्ध है, लेकिन यह अभी भी बीटा में है। इस नए संस्करण में कुछ विशेषताओं को लागू किया जा रहा है जो कि कुछ हद तक गैर-स्पष्ट, या अप्रत्याशित तरीके से लागू की गई हैं। अशक्त संदर्भ प्रकार उनमें से एक हैं। यह सुविधा नल संदर्भ अपवाद (एनआरई) से लड़ने के साधन के रूप में घोषित की गई है।

डेवलपर्स को मदद करने के लिए भाषा को विकसित करना और नई सुविधाओं को प्राप्त करना अच्छा है। संयोग से, कुछ समय पहले, हमने NRE का पता लगाने के लिए PVS-Studio के C # विश्लेषक की क्षमता को काफी बढ़ाया। और अब हम सोच रहे हैं कि यदि विशेष रूप से सामान्य और पीवीएस-स्टूडियो में स्थिर विश्लेषण करने वाले को अभी भी संभावित अशांति के निदान के लिए परेशान होना चाहिए, तो कम से कम नए कोड में जो अशक्त संदर्भ का उपयोग कर रहा होगा, ऐसे डेरेफेर "असंभव" हो जाएंगे? चलो यह स्पष्ट करने की कोशिश करते हैं।

नई सुविधा के पेशेवरों और विपक्ष

हमारे जारी रखने से पहले एक अनुस्मारक: इस पोस्ट को लिखने के रूप में उपलब्ध C # 8.0 का नवीनतम बीटा संस्करण, डिफ़ॉल्ट रूप से अशक्त संदर्भ प्रकार अक्षम है, अर्थात संदर्भ प्रकारों का व्यवहार नहीं बदला है।

यदि हम इस विकल्प को सक्षम करते हैं तो C # 8.0 में बिल्कुल अशक्त संदर्भ प्रकार क्या हैं? वे मूल रूप से एक ही अच्छे पुराने संदर्भ प्रकार हैं सिवाय इसके कि अब आपको 'जोड़ना होगा?' प्रकार नाम के बाद (उदाहरण के लिए, स्ट्रिंग? ), Nullable <T> के समान , अर्थात् अशक्त मान प्रकार (उदाहरण के लिए, int? )। Without? ’के बिना, हमारे स्ट्रिंग प्रकार की व्याख्या अब गैर- अशक्त संदर्भ के रूप में की जाएगी, अर्थात् एक संदर्भ प्रकार जिसे शून्य नहीं सौंपा जा सकता है।

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

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

Nullable Reference को वैश्विक प्रोजेक्ट स्तर पर NullableContextOptions गुण मान के साथ या प्रीप्रोसेसर निर्देश के माध्यम से फ़ाइल स्तर पर जोड़कर सक्षम किया जा सकता है:

#nullable enable string cantBeNull = string.Empty; string? canBeNull = null; cantBeNull = canBeNull!; 

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

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

 #nullable enable String GetStr() { return _count > 0 ? _str : null!; } String str = GetStr(); var len = str.Length; 

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

वैसे, आप कई का उपयोग करके एक ही कोड लिख सकते हैं ! ऑपरेटर, जैसा कि C # अब आपको ऐसा करने की अनुमति देता है (और ऐसा कोड पूरी तरह से अनिवार्य है):

 cantBeNull = canBeNull!!!!!!!; 

इस तरह से लिखकर, हम कहते हैं, विचार पर जोर दें, "देखो, यह शून्य हो सकता है !!!" (हम अपनी टीम में, हम इसे "भावनात्मक" प्रोग्रामिंग कहते हैं)। वास्तव में, वाक्य रचना के पेड़ का निर्माण करते समय, कंपाइलर (रोजलिन से) की व्याख्या करता है ! ऑपरेटर उसी तरह से जैसे यह नियमित कोष्ठक की व्याख्या करता है, जिसका अर्थ है कि आप कई लिख सकते हैं ! आप की तरह के रूप में - जैसे कोष्ठक के साथ। लेकिन अगर आप उनमें से पर्याप्त लिखते हैं, तो आप संकलक को "खटखटा सकते हैं"। शायद यह C # 8.0 की अंतिम रिलीज में तय हो जाएगा।

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

 canBeNull!.ToString(); 

आइए अधिक भावनाओं को जोड़ें:

 canBeNull!!!?.ToString(); 

आप शायद ही कभी वास्तविक कोड में सिंटैक्स की तरह देखेंगे। नल-क्षमा करने वाले ऑपरेटर को लिखकर हम संकलक को बताते हैं, "यह कोड ठीक है, जांच की आवश्यकता नहीं है।" एल्विस ऑपरेटर को जोड़कर हम इसे बताते हैं, “या शायद नहीं; चलो इसे सिर्फ मामले में जांचें। "

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

अशक्त संदर्भ प्रकारों को तोड़ने के अन्य तरीकों पर वापस जाना। इस लेख को लिखने के क्षण के रूप में, जब आपके पास एक समाधान होता है जिसमें कई परियोजनाएं शामिल होती हैं, एक संदर्भ प्रकार के एक चर को पार करते हुए, कहते हैं, एक परियोजना से एक विधि में घोषित विधि से किसी अन्य परियोजना में एक विधि के लिए जिसमें NullableContext है संकलक मान रहा है कि यह एक अशक्त स्ट्रिंग के साथ काम कर रहा है और संकलक चुप रहेगा। और यह है कि [अशक्त (1)] टन के बावजूद Nullable सन्दर्भ को सक्षम करते हुए IL कोड में हर क्षेत्र और पद्धति में विशेषताएँ जोड़ी गई हैं । यदि आप विशेषताओं को संभालने के लिए प्रतिबिंब का उपयोग करते हैं और यह मान लेते हैं कि कोड में केवल आपके कस्टम शामिल हैं, तो इन विशेषताओं को ध्यान में रखा जाना चाहिए।

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

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

पीवीएस-स्टूडियो अशक्त संदर्भ अपवादों के लिए कैसा दिखता है

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

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

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

 #nullable enable String GetStr() { return _count > 0 ? _str : null!; } String str = GetStr(); var len = str.Length; <== V3080: Possible null dereference. Consider inspecting 'str' 

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

V3080 [CWE-476] संभव शून्य विध्वंस विधि के अंदर। 2 तर्क का निरीक्षण करने पर विचार करें: chainedTupleType। Microsoft.CodeAnalysis.CSharp TupleTypeSymbol.cs 244

 NamedTypeSymbol chainedTupleType; if (_underlyingType.Arity < TupleTypeSymbol.RestPosition) { .... chainedTupleType = null; } else { .... } return Create(ConstructTupleUnderlyingType(firstTupleType, chainedTupleType, newElementTypes), elementNames: _elementNames); 

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

 internal static NamedTypeSymbol ConstructTupleUnderlyingType( NamedTypeSymbol firstTupleType, NamedTypeSymbol chainedTupleTypeOpt, ImmutableArray<TypeWithAnnotations> elementTypes) { Debug.Assert (chainedTupleTypeOpt is null == elementTypes.Length < RestPosition); .... while (loop > 0) { .... currentSymbol = chainedTupleTypeOpt.Construct(chainedTypes); loop--; } return currentSymbol; } 

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

यह एक ग्राफिक उदाहरण है कि कैसे आप डिबग का इलाज करने वाले कंपाइलर के नुल्ले रेफरबेक्यूज़ से परेशानी में पड़ सकते हैं। यदि आप #nullable enable को जोड़ते हैं और chainedTupleTypeOpt तर्क को एक अशक्त संदर्भ के रूप में चिह्नित करते हैं , तो संकलक ConstructTupleUnderlyingType विधि के अंदर डेरेफेरेशन पर कोई चेतावनी जारी नहीं करेगा।

पीवीएस-स्टूडियो द्वारा चेतावनियों के अन्य उदाहरणों पर चलते हुए।

V3080 संभव अशक्तता। निरीक्षण 'प्रभावीRuleset' पर विचार करें। RuleSet.cs 146

 var effectiveRuleset = ruleSet.GetEffectiveRuleSet(includedRulesetPaths); effectiveRuleset = effectiveRuleset.WithEffectiveAction(ruleSetInclude.Action); if (IsStricterThan(effectiveRuleset.GeneralDiagnosticOption, ....)) effectiveGeneralOption = effectiveRuleset.GeneralDiagnosticOption; 

यह चेतावनी कहती है कि WithEffectiveAction पद्धति की कॉल अशक्त हो सकती है, जबकि चर प्रभावी करने के लिए असाइन किया गया रिटर्न मान का उपयोग करने से पहले जाँच नहीं की जाती है ( प्रभावी Ruleset.GeneralDiagnosticOption )। यहाँ निकाय विचलन विधि का अंग है:

 public RuleSet WithEffectiveAction(ReportDiagnostic action) { if (!_includes.IsEmpty) throw new ArgumentException(....); switch (action) { case ReportDiagnostic.Default: return this; case ReportDiagnostic.Suppress: return null; .... return new RuleSet(....); default: return null; } } 

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

 private static bool IsStricterThan(ReportDiagnostic action1, ReportDiagnostic action2) { switch (action2) { case ReportDiagnostic.Suppress: ....; case ReportDiagnostic.Warn: return action1 == ReportDiagnostic.Error; case ReportDiagnostic.Error: return false; default: return false; } } 

जैसा कि आप देख सकते हैं, यह दो सरलताओं के बीच चयन करने वाला एक साधारण स्विच स्टेटमेंट है, डिफ़ॉल्ट मान के रूप में ReportDiagnostic.Default । इसलिए कॉल को फिर से लिखना सबसे अच्छा होगा:

WithEffectiveAction का हस्ताक्षर बदल जाएगा:

 #nullable enable public RuleSet? WithEffectiveAction(ReportDiagnostic action) 

इस तरह से कॉल लगेगा:

 RuleSet? effectiveRuleset = ruleSet.GetEffectiveRuleSet(includedRulesetPaths); effectiveRuleset = effectiveRuleset?.WithEffectiveAction(ruleSetInclude.Action); if (IsStricterThan(effectiveRuleset?.GeneralDiagnosticOption ?? ReportDiagnostic.Default, effectiveGeneralOption)) effectiveGeneralOption = effectiveRuleset.GeneralDiagnosticOption; 

चूंकि IsStricterThan केवल तुलना करता है, इसलिए हालत फिर से लिखी जा सकती है - उदाहरण के लिए, इस तरह:

 if (effectiveRuleset == null || IsStricterThan(effectiveRuleset.GeneralDiagnosticOption, effectiveGeneralOption)) 

अगला उदाहरण।

V3080 संभव अशक्तता। 'प्रॉपर्टीसंबॉल' का निरीक्षण करने पर विचार करें। BinderFactory.BinderFactoryVisitor.cs 372

 var propertySymbol = GetPropertySymbol(parent, resultBinder); var accessor = propertySymbol.GetMethod; if ((object)accessor != null) resultBinder = new InMethodBinder(accessor, resultBinder); 

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

 private SourcePropertySymbol GetPropertySymbol( BasePropertyDeclarationSyntax basePropertyDeclarationSyntax, Binder outerBinder) { .... NamedTypeSymbol container = GetContainerType(outerBinder, basePropertyDeclarationSyntax); if ((object)container == null) return null; .... return (SourcePropertySymbol)GetMemberSymbol(propertyName, basePropertyDeclarationSyntax.Span, container, SymbolKind.Property); } 

GetMemberSymbol विधि, भी, कुछ शर्तों के तहत अशक्त लौटा सकती है।

 private Symbol GetMemberSymbol( string memberName, TextSpan memberSpan, NamedTypeSymbol container, SymbolKind kind) { foreach (Symbol sym in container.GetMembers(memberName)) { if (sym.Kind != kind) continue; if (sym.Kind == SymbolKind.Method) { .... var implementation = ((MethodSymbol)sym).PartialImplementationPart; if ((object)implementation != null) if (InSpan(implementation.Locations[0], this.syntaxTree, memberSpan)) return implementation; } else if (InSpan(sym.Locations, this.syntaxTree, memberSpan)) return sym; } return null; } 

अशक्त संदर्भ प्रकार सक्षम होने के साथ, कॉल इसमें बदल जाएगी:

 #nullable enable SourcePropertySymbol? propertySymbol = GetPropertySymbol(parent, resultBinder); MethodSymbol? accessor = propertySymbol?.GetMethod; if ((object)accessor != null) resultBinder = new InMethodBinder(accessor, resultBinder); 

यह ठीक करना बहुत आसान है जब आप जानते हैं कि कहाँ देखना है। स्थैतिक विश्लेषण इस संभावित त्रुटि को सभी प्रक्रिया कॉल श्रृंखला से क्षेत्र के सभी संभावित मूल्यों को इकट्ठा करके बिना किसी प्रयास के पकड़ सकता है।

V3080 संभव अशक्तता। 'SimpleName' के निरीक्षण पर विचार करें। CSharpCommandLineParser.cs 1556

 string simpleName; simpleName = PathUtilities.RemoveExtension( PathUtilities.GetFileName(sourceFiles.FirstOrDefault().Path)); outputFileName = simpleName + outputKind.GetDefaultExtension(); if (simpleName.Length == 0 && !outputKind.IsNetModule()) .... 

समस्या simpleName.Length जाँच के अनुरूप है । परिवर्तनशील सरल नाम विधियों की एक लंबी श्रृंखला को निष्पादित करने से उत्पन्न होता है और इसे निरर्थक सौंपा जा सकता है। वैसे, यदि आप उत्सुक हैं, तो आप यह देखने के लिए RemoveExtension विधि को देख सकते हैं कि यह Path.GetFileNameWithoutExtension से कैसे भिन्न है । एक साधारण नाम! = अशक्त चेक पर्याप्त होगा, लेकिन गैर- अशक्त संदर्भ प्रकारों के साथ, कोड कुछ इस तरह बदल जाएगा:

 #nullable enable public static string? RemoveExtension(string path) { .... } string simpleName; 

इस तरह से कॉल लग सकता है:

 simpleName = PathUtilities.RemoveExtension( PathUtilities.GetFileName(sourceFiles.FirstOrDefault().Path)) ?? String.Empty; 

निष्कर्ष

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

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

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