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

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

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

नवाचार के पेशेवरों और विपक्ष

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

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

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

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

आप पूरे प्रोजेक्ट स्तर पर 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(); 

यह वाक्यविन्यास वास्तव में एक वास्तविक परियोजना में कल्पना करना मुश्किल है, एक शून्य-क्षमाशील ऑपरेटर डालकर हम संकलक को बताते हैं: यहां सब कुछ ठीक है, कोई सत्यापन की आवश्यकता नहीं है। एक एल्विस ऑपरेटर जोड़ते हुए हम कहते हैं: लेकिन सामान्य तौर पर यह सामान्य नहीं हो सकता है, आइए देखें।

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

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

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

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

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

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

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

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 निदान के ऐसे ट्रिगर के कुछ उदाहरणों पर विचार करें। हमने इस परियोजना को बहुत पहले नहीं देखा था, लेकिन इस बार हम केवल संभावित संदर्भ संदर्भ अपवाद पर विचार करेंगे जो पिछले लेखों में नहीं थे। आइए देखें कि पीवीएस-स्टूडियो विश्लेषक अशक्त संदर्भों की संभावित डेरेफेरिंग कैसे पा सकते हैं, और इन स्थानों को नए अशक्त संदर्भ सिंटैक्स का उपयोग करके कैसे तय किया जा सकता है।

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 चर कोड निष्पादन शाखाओं में से एक में शून्य हो सकता है। तब chainedTupleType को ConstructTupleUnderlyingType विधि के अंदर पास किया जाता है , और इसका उपयोग Debug.Assert के माध्यम से सत्यापन के साथ किया जाता है। रोसलिन में यह स्थिति बहुत ही सामान्य है, हालांकि, यह याद रखने योग्य है कि डीबग। एसेर को विधानसभा के रिलीज संस्करण में हटा दिया गया है। इसलिए, विश्लेषक अभी भी 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 से अनुबंध, उदाहरण के लिए, विश्लेषक अब ध्यान में रखता है। मैं आपको हमारे विश्लेषक में उसी रोजलिन के वास्तविक उपयोग से केवल एक छोटा सा उदाहरण बताऊंगा। हाल ही में, हमने विज़ुअल स्टूडियो के नए संस्करण का समर्थन किया , और उसी समय रोसलिन विश्लेषक को संस्करण 3 में अपडेट किया। उसके बाद, एक निश्चित कोड की जांच करते समय विश्लेषक गिरना शुरू हो गया, जिस पर यह पहले दुर्घटनाग्रस्त नहीं हुआ था। उसी समय, विश्लेषक हमारे कोड के अंदर नहीं, बल्कि खुद रोसलिन के कोड के अंदर गिरना शुरू कर दिया - एक अशक्त संदर्भ अपवाद के साथ। और आगे डिबगिंग से पता चला कि जिस जगह पर रोजलिन अब गिरती है, ठीक ऊपर की एक-दो लाइनें, डेब्यू.एसर के माध्यम से एक ही अशक्त जांच है। और वह, जैसा कि हम देखते हैं, बचा नहीं था।

यह अशक्त संदर्भ के साथ समस्याओं का एक बहुत अच्छा उदाहरण है , क्योंकि कंपाइलर डीबग को मानता है। किसी भी कॉन्फ़िगरेशन में एक मान्य चेक का उपयोग करता है। यही है, अगर आप बस # सक्षम सक्षम करते हैं और ज्वलनशील संदर्भ के रूप में 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 पद्धति को कॉल करने पर अशक्त वापस आ सकता है, लेकिन परिणाम का उपयोग चेकिंग के बिना किया जाता है। WithEffectiveAction पद्धति का निकाय, जो अशक्त हो सकता है, प्रभावी Ruleset चर को लिखा जाता है:

 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 विधि के लिए अशक्त संदर्भ मोड को सक्षम करते हैं, तो हमारे पास दो स्थान होंगे जिसमें हमें व्यवहार को बदलना होगा। चूंकि ऊपर की विधि में एक अपवाद फेंक है, इसलिए यह मानना ​​तर्कसंगत है कि विधि कॉल को एक कोशिश-पकड़ने वाले ब्लॉक में लपेटा गया है और यह सही तरीके से फिर से लिख देगा, नल को वापस करने के बजाय अपवाद फेंक रहा है। लेकिन चुनौतियों पर चढ़ते हुए, हम देखते हैं कि अवरोधन अधिक है और परिणाम काफी अप्रत्याशित हो सकते हैं। आइए उपभोक्ता चर प्रभावी Ruleset - 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 की जाँच के साथ है । simpleName तरीकों की एक पूरी श्रृंखला का परिणाम है और अशक्त हो सकता है। वैसे, जिज्ञासा के लिए, आप RemoveExtension विधि को देख सकते हैं और पाथ से अंतर पा सकते हैं। GetFileNameWithoutExtension। यहाँ हम खुद को साधारण नाम जाँचने के लिए सीमित कर सकते हैं ! = अशक्त , लेकिन गैर-शून्य लिंक के संदर्भ में, कोड कुछ इस तरह दिखेगा:

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

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

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

निष्कर्ष

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

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

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

यदि आप इस लेख को एक अंग्रेजी-भाषी दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: पॉल एरेमीव, अलेक्जेंडर रेनकिन। C # 8.0 और स्थैतिक विश्लेषण में अशक्त संदर्भ प्रकार