👶🏼 👩🏾‍⚖️ 🚶🏾 .NET में विशेष अपवाद और उन्हें कैसे तैयार किया जाए 🕵🏻 🐅 🧑🏻‍🤝‍🧑🏻

.NET में विभिन्न अपवादों की अपनी विशेषताएं हैं, और उन्हें जानना बहुत उपयोगी हो सकता है। CLR ट्रिक कैसे करे? StackOverflowException को पकड़कर रनटाइम में जीवित कैसे रहें? क्या अपवादों को पकड़ना असंभव लगता है, लेकिन अगर आप वास्तव में चाहते हैं, तो आप कर सकते हैं?

कटौती के तहत, हमारे डॉटनेक्स्ट 2018 पाइटर सम्मेलन से यूजीन ( एपेशक ) पेशकोव की रिपोर्ट की प्रतिलिपि, जहां उन्होंने इन और अपवादों की अन्य विशेषताओं के बारे में बात की।

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

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

आज मैं .NET में अपवादों की विशेषताओं के बारे में बात करूंगा। हमने उत्पादन में इन विशेषताओं में से कुछ का सामना किया, और उनमें से कुछ प्रयोगों के दौरान।

योजना

.NET अपवाद व्यवहार
विंडोज अपवाद हैंडलिंग और हैक

निम्न में से सभी Windows के लिए सही है। सभी उदाहरणों को पूर्ण .NET 4.7.1 ढांचे के नवीनतम संस्करण पर परीक्षण किया गया था। .NET Core के कुछ संदर्भ भी होंगे।

पहुंच का उल्लंघन

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

आइए C # का उपयोग करके इस अपवाद को प्राप्त करने का प्रयास करें। ऐसा करने के लिए, हम पता 1000 को बाइट 42 लिखते हैं (हम मानते हैं कि 1000 एक काफी यादृच्छिक पता है और हमारे आवेदन की सबसे अधिक संभावना नहीं है)।

try { Marshal.WriteByte((IntPtr) 1000, 42); } catch (AccessViolationException) { ... }

WriteByte को बस वही चाहिए जो हमें चाहिए: यह दिए गए पते पर एक बाइट लिखता है। हम उम्मीद करते हैं कि यह कॉल AccessViolationException को फेंक देगा। यह कोड वास्तव में इस अपवाद को फेंक देगा, यह संभाल करने में सक्षम होगा और एप्लिकेशन काम करना जारी रखेगा। अब कोड को थोड़ा बदलें:

 try { var bytes = new byte[] {42}; Marshal.Copy(bytes, 0, (IntPtr) 1000, bytes.Length); } catch (AccessViolationException) { ... }

अगर WriteByte के बजाय आप कॉपी विधि का उपयोग करते हैं और बाइट 42 को पता 1000 तक कॉपी करते हैं, तो ट्राइ-कैच का उपयोग करके, AccessViolation को नहीं पकड़ा जा सकता है। उसी समय, कंसोल पर एक संदेश प्रदर्शित किया जाएगा जिसमें कहा गया है कि एक अनचाहे AccessViolusException के कारण एप्लिकेशन समाप्त हो गया था।

 Marshal.Copy(bytes, 0, (IntPtr) 1000, bytes.Length); Marshal.WriteByte((IntPtr) 1000, 42);

यह पता चला है कि हमारे पास कोड की दो पंक्तियाँ हैं, जबकि पहला AccessViolation के साथ पूरे एप्लिकेशन को क्रैश कर देता है, और दूसरा उसी प्रकार के प्रोसेस्ड अपवाद को फेंक देता है। ऐसा क्यों होता है, यह समझने के लिए, हम देखेंगे कि इन तरीकों को अंदर से कैसे व्यवस्थित किया जाता है।

चलो कॉपी विधि से शुरू करते हैं।

 static void Copy(...) { Marshal.CopyToNative((object) source, startIndex, destination, length); } [MethodImpl(MethodImplOptions.InternalCall)] static extern void CopyToNative(object source, int startIndex, IntPtr destination, int length);

केवल एक ही प्रतिलिपि विधि करता है। CopyToNative विधि को कॉल करें। .NET के अंदर कार्यान्वित किया जाता है। यदि हमारा एप्लिकेशन अभी भी क्रैश होता है और कहीं अपवाद होता है, तो यह केवल CopyToNative के अंदर हो सकता है। यहाँ से हम पहला अवलोकन कर सकते हैं: यदि .NET कोड को नेटिव कोड कहा जाता है और AccessViolation इसके अंदर होता है, तो .NET कोड किसी कारण से इस अपवाद को नहीं संभाल सकता है।

अब हम समझेंगे कि WriteByte पद्धति का उपयोग करके AccessViolation को संसाधित करना क्यों संभव था। आइए इस विधि के कोड को देखें:

 unsafe static void WriteByte(IntPtr ptr, byte val) { try { *(byte*) ptr = val; } catch (NullReferenceException) {     // this method is documented to throw AccessViolationException on any AV throw new AccessViolationException(); } }

यह विधि पूरी तरह से प्रबंधित कोड में लागू है। यह वांछित पते पर डेटा लिखने के लिए C #-पॉइंटर का उपयोग करता है, और NullReferenceException को भी पकड़ता है। यदि NRE को इंटरसेप्ट किया गया है, तो AccessViolationException को फेंक दिया जाता है। इसलिए स्पेसिफिकेशन की वजह से यह जरूरी है। इस मामले में, थ्रो कंस्ट्रक्शन द्वारा फेंके गए सभी अपवादों को नियंत्रित किया जाता है। तदनुसार, अगर WriteByte के अंदर कोड निष्पादन के दौरान एक NullReferenceException होती है, तो हम AccessViolation को पकड़ सकते हैं। क्या एक एनआरई हो सकता है, हमारे मामले में, जब पते को शून्य के बजाय 1000 तक पहुँचा जा सकता है?

हम सीधे C # पॉइंटर्स का उपयोग करते हुए कोड को फिर से लिखते हैं, और देखते हैं कि जब एक गैर-शून्य पते पर पहुंच जाता है, तो एक NullReferenceException वास्तव में फेंक दिया जाता है:

 *(byte*) 1000 = 42;

यह समझने के लिए कि ऐसा क्यों होता है, हमें यह याद रखने की आवश्यकता है कि प्रक्रिया की मेमोरी कैसे काम करती है। प्रक्रिया मेमोरी में, सभी पते आभासी हैं। इसका मतलब है कि एप्लिकेशन में एक बड़ी पता जगह है और इसमें से केवल कुछ पृष्ठ वास्तविक भौतिक मेमोरी में प्रदर्शित किए गए हैं। लेकिन एक विशेषता है: पहले 64 केबी के पते को कभी भी भौतिक मेमोरी में मैप नहीं किया जाता है और इसे एप्लिकेशन को नहीं दिया जाता है। Rantime .NET यह जानता है और इसका उपयोग करता है। यदि AccessViolation प्रबंधित कोड में हुआ है, तो रनटाइम चेक जो मेमोरी में पता एक्सेस किया गया था और एक उपयुक्त अपवाद उत्पन्न करता है। 0 से 2 ^ 16 तक के पते के लिए - सभी के लिए NullReference, AccessViolation।

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

इस स्थिति में, हम NullReferenceException प्राप्त करने की अपेक्षा करते हैं। किसी वस्तु के क्षेत्र तक पहुंच इस वस्तु के पते के सापेक्ष ऑफसेट द्वारा होती है। यह पता चला है कि हम एक ऐसे पते पर जाएंगे जो शून्य के करीब है (याद रखें कि हमारी मूल वस्तु का लिंक शून्य है)। इस रनटाइम व्यवहार के साथ, हमें स्वयं वस्तु के पते के अतिरिक्त सत्यापन के बिना अपेक्षित अपवाद मिलता है।

लेकिन अगर हम किसी वस्तु के क्षेत्र की ओर मुड़ जाते हैं और क्या होता है, और यह वस्तु स्वयं 64 केबी से अधिक का हो जाती है?

क्या हम इस मामले में AccessViolation प्राप्त कर सकते हैं? चलो एक प्रयोग करते हैं। चलो एक बहुत बड़ी वस्तु बनाते हैं और हम इसके क्षेत्रों का उल्लेख करेंगे। ऑब्जेक्ट की शुरुआत में एक फ़ील्ड, अंत में दूसरा:

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

यह ध्यान देने योग्य है कि इस प्रयोग के लिए एक सरणी को एक बड़ी वस्तु के रूप में उपयोग करना पर्याप्त नहीं है। क्यों? इस सवाल को पाठक पर छोड़ें, टिप्पणियों में विचार लिखें :)

चलो AccessViolation के साथ प्रयोगों को संक्षेप में प्रस्तुत करते हैं।

AccessViolationException अलग तरीके से व्यवहार करती है जहां पर अपवाद हुआ (प्रबंधित कोड में या मूल में)। इसके अलावा, यदि प्रबंधित कोड में कोई अपवाद हुआ है, तो ऑब्जेक्ट का पता चेक किया जाएगा।

सवाल यह है: क्या हम एक AccessViolationException को संभाल सकते हैं जो मूल कोड या प्रबंधित कोड में हुई थी, लेकिन NullReference में परिवर्तित नहीं हुई और न ही थ्रो का उपयोग करके इसे फेंक दिया गया? यह कभी-कभी एक उपयोगी विशेषता है, खासकर जब असुरक्षित कोड के साथ काम कर रहा हो। इस प्रश्न का उत्तर .NET के संस्करण पर निर्भर करता है।

.NET 1.0 में, कोई AccessViolationException बिल्कुल नहीं थी। सभी लिंक को वैध या अशक्त माना जाता था। .NET 2.0 के समय तक, यह स्पष्ट हो गया कि मेमोरी के साथ सीधे काम के बिना - कोई रास्ता नहीं, और AccessViolation दिखाई दिया, जबकि यह प्रक्रियात्मक था। 4.0 और इसके बाद के संस्करण में, यह अभी भी व्यावहारिक है, लेकिन इसे संसाधित करना इतना सरल नहीं है। इस अपवाद को पकड़ने के लिए, अब आपको उस विधि को चिह्नित करने की आवश्यकता है जिसमें कैच ब्लॉक हैंडलेप्रोसेसक्रॉप्टेडस्टैटटेसेप्शन विशेषता के साथ स्थित है। जाहिर है, डेवलपर्स ने ऐसा किया क्योंकि उन्हें लगा कि AccessViolationException अपवाद नहीं थी जिसे एक नियमित अनुप्रयोग में पकड़ा जाना चाहिए।
इसके अलावा, पिछड़ी संगतता के लिए, रनटाइम सेटिंग्स का उपयोग करना संभव है:

legacyNullReferenceExceptionPolicy रिटर्न .NET 1.0 व्यवहार - सभी AVs NRE में बदल जाते हैं
legacyCorruptedStateExceptionPolicy रिटर्न .NET 2.0 व्यवहार - सभी AV इंटरसेप्टेड हैं

.NET में, Core AccessViolation को संभाला नहीं जाता है।

हमारे उत्पादन में ऐसी स्थिति थी:

.NET 4.7.1 के तहत बनाया गया एक एप्लिकेशन .NET 3.5 के तहत निर्मित एक साझा कोड लाइब्रेरी का उपयोग करता है। इस पुस्तकालय में एक आवधिक कार्रवाई चलाने के लिए एक सहायक था:

 while (isRunning) { try { action(); } catch (Exception e) { log.Error(e); } WaitForNextExecution(... ); }

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

संक्षेप में देना। AccessVilolation प्रोसेसिंग इस पर निर्भर करती है कि यह कहां से उत्पन्न हुआ है - देशी या प्रबंधित कोड में और साथ ही टारगेटफ्रॉमवर्क और रनटाइम सेटिंग्स।

धागा गर्भपात

कभी-कभी कोड में आपको थ्रेड्स में से एक के निष्पादन को रोकने की आवश्यकता होती है। ऐसा करने के लिए, आप थ्रेड का उपयोग कर सकते हैं। एबोर्ट ();

 var thread = new Thread(() => { try { ... } catch (ThreadAbortException e) { ... Thread.ResetAbort(); } }); ... thread.Abort();

जब एबॉर्ट विधि को एक थ्रेड थ्रेड में कहा जाता है, तो एक थ्रेडबोर्ट एक्ससेप्शन फेंका जाता है। आइए इसकी विशेषताओं का विश्लेषण करते हैं। उदाहरण के लिए, एक कोड इस तरह:

 var thread = new Thread(() => { try { … } catch (ThreadAbortException e) { … } }); ... thread.Abort();

इसके बिल्कुल बराबर:

 var thread = new Thread(() => { try { ... } catch (ThreadAbortException e) { ... throw; } }); ... thread.Abort();

यदि आपको थ्रेडअबोर्ट को संसाधित करने और बंद किए गए थ्रेड में कुछ अन्य क्रियाएं करने की आवश्यकता है, तो आप Thread.ResetAbort () विधि का उपयोग कर सकते हैं; यह प्रवाह को रोकने की प्रक्रिया को रोकता है और अपवाद स्टैक को उच्चतर फेंकना बंद कर देता है। यह समझना महत्वपूर्ण है कि थ्रेड। एबॉर्ट () विधि स्वयं कुछ भी गारंटी नहीं देती है - बंद धागे में कोड इसे रोकने से रोक सकता है।

थ्रेड की एक अन्य विशेषता। एबोर्ट () यह है कि यह कोड को बाधित करने में सक्षम नहीं होगा यदि यह पकड़ में है और अंत में ब्लॉक है।

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

इसके अलावा, थ्रेड के लिए एक कॉल .bort () विधि पिरोया जाने के लिए एक ThreadAbortException की प्रतीक्षा करता है। इन दोनों तथ्यों को मिलाएं और प्राप्त करें कि थ्रेड। एबॉर्ट () विधि कॉलिंग थ्रेड को ब्लॉक कर सकती है।

 var thread = new Thread(() => {   try { }       catch { } // <-- No ThreadAbortException in catch       finally { // <-- No ThreadAbortException in finally           Thread.Sleep(- 1); } }); thread.Start(); ... thread.Abort(); // Never returns

वास्तव में, इसका उपयोग करते समय सामना किया जा सकता है। यह कोशिश में तैनात है / अंत में, अंत में अंदर, निपटान विधि कहा जाता है। यह मनमाने ढंग से जटिल हो सकता है, घटना संचालकों को शामिल कर सकता है, ताले का उपयोग कर सकता है। और अगर थ्रेड। एबॉर्ट को रन टाइम पर बुलाया गया था, तो डिस्पोज़ - थ्रेड। एबॉर्ट () इसके लिए इंतजार करेगा। तो हमें खरोंच से लगभग एक ताला मिलता है।

.NET कोर में, Thread.Abort () विधि एक PlatformNotSupportedException फेंकता है। और मुझे लगता है कि यह बहुत अच्छा है, क्योंकि यह मुझे थ्रेड एबोर्ट () का उपयोग करने के लिए प्रेरित करता है, लेकिन कोड निष्पादन को रोकने के लिए गैर-इनवेसिव तरीके, उदाहरण के लिए कैंसिलेशनटोकन का उपयोग करना।

याद से बाहर

यह अपवाद प्राप्त किया जा सकता है यदि मशीन पर मेमोरी आवश्यकता से कम है। या जब हम 32-बिट प्रक्रिया की सीमाओं में भाग गए। लेकिन आप इसे प्राप्त कर सकते हैं भले ही कंप्यूटर में बहुत सारी मुफ्त मेमोरी हो, और प्रक्रिया 64-बिट है।

 var arr4gb = new int[int.MaxValue/2];

ऊपर वाला कोड OutOfMemory फेंक देगा। बात यह है कि, डिफ़ॉल्ट रूप से, 2 जीबी से बड़ी वस्तुओं की अनुमति नहीं है। यह App.config में gcAllowVeryLargeObjects सेट करके तय किया जा सकता है। इस स्थिति में, 4 जीबी सरणी बनाई जाती है।

अब एक और भी अरै बनाने की कोशिश करते हैं।

 var largeArr = new int[int.MaxValue];

अब भी gcAllowVeryLargeObjects मदद नहीं करेगा। ऐसा इसलिए है क्योंकि किसी सरणी में अधिकतम सूचकांक पर .NET की सीमा है । यह प्रतिबंध int.MaxValue से कम है।

अधिकतम सरणी सूचकांक:

बाइट सरणियाँ - 0x7FFFFFC7
अन्य सरणियाँ - 0X7F E FFFFF

इस मामले में, एक OutOfMemoryException उत्पन्न होगी, हालांकि वास्तव में हम डेटा प्रकार प्रतिबंध के खिलाफ आए हैं, स्मृति की कमी नहीं।

कभी-कभी OutOfMemory को .NET फ्रेमवर्क के अंदर प्रबंधित कोड द्वारा स्पष्ट रूप से फेंक दिया जाता है:

यह string.Concat पद्धति का कार्यान्वयन है। यदि परिणाम स्ट्रिंग की लंबाई int.MaxValue से अधिक है, तो एक OutOfMemoryException को तुरंत फेंक दिया जाता है।

चलो उस स्थिति पर चलते हैं जब आउटऑफ़मेरी मामले में उठता है जब मेमोरी वास्तव में बाहर निकलती है।

 LimitMemory(64.Mb()); try { while (true)   list.Add(new byte[size]); } catch (OutOfMemoryException e) { Console.WriteLine(e); }

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

इस मामले में, कुछ भी हो सकता है:

अपवाद संभाला
प्रक्रिया गिर जाएगी
चलो पकड़ में आते हैं, लेकिन अपवाद फिर से दुर्घटनाग्रस्त हो जाएगा
चलो पकड़ में आते हैं, लेकिन StackOverflow दुर्घटना होगी

इस मामले में, कार्यक्रम पूरी तरह से गैर-नियतात्मक होगा। आइए सभी विकल्पों का विश्लेषण करें:

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

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

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

निम्न कोड आपको स्ट्रीम की शुरुआत में एक बार में सभी मेमोरी को स्टैक करने की अनुमति देगा।

 new Thread(() => F(), 4*1024*1024).Start();

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

ढेर अतिप्रवाह

चलो StackOverflowException पर करीब से नज़र डालें। आइए दो कोड उदाहरण देखें। उनमें से एक में, हम अनंत पुनरावृत्ति चलाते हैं, जो एक स्टैक ओवरफ्लो की ओर जाता है, दूसरे में हम सिर्फ इस अपवाद को फेंक देते हैं।

 try { InfiniteRecursion(); } catch (Exception) { ... }

 try { throw new StackOverflowException(); } catch (Exception) { ... }

चूंकि सभी अपवादों को फेंक दिया जाता है, उन्हें संभाला जाता है, दूसरे मामले में हम अपवाद को पकड़ लेंगे। और पहले मामले के साथ, सब कुछ अधिक दिलचस्प है। MSDN की ओर मुड़ें:

"आप स्टैक ओवरफ़्लो अपवादों को नहीं पकड़ सकते, क्योंकि अपवाद-हैंडलिंग कोड को स्टैक की आवश्यकता हो सकती है।"
MSDN

यह यहां कहता है कि हम एक StackOverflowException को नहीं पकड़ पाएंगे, क्योंकि अवरोधन के लिए अतिरिक्त स्टैक स्पेस की आवश्यकता हो सकती है जो पहले ही समाप्त हो चुका है।

किसी तरह इस अपवाद से बचाव के लिए, हम निम्नलिखित कार्य कर सकते हैं। सबसे पहले, आप पुनरावृत्ति की गहराई को सीमित कर सकते हैं। दूसरे, आप RuntimeHelpers वर्ग के तरीकों का उपयोग कर सकते हैं:

RuntimeHelpers.EnsureSufficientExecutionStack ();

"यह सुनिश्चित करता है कि शेष स्टैक स्पेस औसत .NET फ्रेमवर्क फ़ंक्शन को निष्पादित करने के लिए पर्याप्त बड़ा है।" - MSDN
InsufficientExecutionStackException
512 KB - x86, AnyCPU, 2 MB - x64 (स्टैक आकार का आधा)
64/128 KB - .NET कोर
केवल स्टैक पता स्थान की जाँच करें

इस पद्धति के लिए प्रलेखन का कहना है कि यह जांचता है कि औसत .NET फ़ंक्शन को निष्पादित करने के लिए स्टैक पर पर्याप्त जगह है। लेकिन औसत फ़ंक्शन क्या है? वास्तव में, .NET फ्रेमवर्क में यह विधि पुष्टि करती है कि स्टैक पर इसका कम से कम आधा आकार मुफ्त है। .NET Core में, यह 64K फ्री में चेक करता है।

.NET कोर में एक एनालॉग भी दिखाई दिया है: RuntimeHelpers.TryEnsureSufficientExecutionStack () जो एक अपवाद वापस करने के बजाय एक बूल लौटाता है।

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

 Span<byte> span; if (CanAllocateOnStack(size)) span = stackalloc byte[size]; else span = new byte[size];

MSDN पर StackOverflow के दस्तावेज़ पर वापस जाएँ

इसके बजाय, जब एक सामान्य अनुप्रयोग में स्टैक ओवरफ़्लो होता है, तो कॉमन लैंग्वेज रनटाइम (CLR) प्रक्रिया को समाप्त कर देती है। ”
MSDN

यदि कोई "सामान्य" अनुप्रयोग है जो StackOverflow के दौरान गिरता है, तो गैर-सामान्य अनुप्रयोग हैं जो गिरते नहीं हैं? इस प्रश्न का उत्तर देने के लिए, आपको प्रबंधित एप्लिकेशन स्तर से CLR स्तर तक एक स्तर नीचे जाना होगा।

"एक एप्लिकेशन जो सीएलआर को होस्ट करता है वह डिफ़ॉल्ट व्यवहार को बदल सकता है और निर्दिष्ट कर सकता है कि सीएलआर उस एप्लिकेशन डोमेन को लोड करता है जहां अपवाद होता है, लेकिन प्रक्रिया को जारी रखने देता है।" - MSDN
StackOverflowException -> AppDomainUnloadedException

एक एप्लिकेशन जो सीएलआर को होस्ट करता है, स्टैक ओवरफ्लो के व्यवहार को फिर से परिभाषित कर सकता है ताकि पूरी प्रक्रिया को पूरा करने के बजाय, एप्लिकेशन डोमेन अनलोड हो, जिस स्ट्रीम में यह ओवरफ्लो हुआ। तो हम एक StackOverflowException को AppDomainUnloadedException में बदल सकते हैं।

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

निम्न कोड CLR- होस्ट को कॉन्फ़िगर करता है ताकि StackOverflow के दौरान AppDomain (C ++) अनलोड हो जाए:

 ICLRPolicyManager *policyMgr; pCLRControl->GetCLRManager(IID_ICLRPolicyManager, (void**) (&policyMgr)); policyMgr->SetActionOnFailure(FAIL_StackOverflow, eRudeUnloadAppDomain);

क्या यह StackOverflow से बचने का अच्छा तरीका है? शायद बहुत नहीं। सबसे पहले, हमें C ++ कोड लिखना होगा, जिसे हम नहीं करना चाहेंगे। दूसरे, हमें अपना C # कोड बदलना होगा ताकि StackOverflowException को फेंकने वाले फ़ंक्शन को एक अलग AppDomain और एक अलग थ्रेड में निष्पादित किया जा सके। हमारा कोड तुरंत ऐसे नूडल्स में बदल जाएगा:

 try { var appDomain = AppDomain.CreateDomain("..."); appDomain.DoCallBack(() => { var thread = new Thread(() => InfiniteRecursion()); thread.Start(); thread.Join(); }); AppDomain.Unload(appDomain); } catch (AppDomainUnloadedException) { }

InfiniteRecursion विधि को कॉल करने के लिए, हमने लाइनों का एक गुच्छा लिखा। तीसरा, हमने AppDomain का उपयोग शुरू किया। और यह लगभग नई समस्याओं का एक समूह है। अपवादों सहित। एक उदाहरण पर विचार करें:

 public class CustomException : Exception {} var appDomain = AppDomain.CreateDomain( "..."); appDomain.DoCallBack(() => throw new CustomException()); System.Runtime.Serialization.SerializationException: Type 'CustomException' is not marked as serializable. at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)

चूँकि हमारे अपवाद को अनुक्रमिक के रूप में चिह्नित नहीं किया गया है, इसलिए हमारा कोड एक SerializationException के साथ गिर जाएगा। और इस समस्या को ठीक करने के लिए, यह हमारे लिए पर्याप्त नहीं है कि हम अपने अपवाद को Serializable विशेषता के साथ चिह्नित करें, हमें अभी भी क्रमांकन के लिए एक अतिरिक्त निर्माता को लागू करने की आवश्यकता है।

 [Serializable] public class CustomException : Exception { public CustomException(){} public CustomException(SerializationInfo info, StreamingContext ctx) : base(info, context){} } var appDomain = AppDomain.CreateDomain("..."); appDomain.DoCallBack(() => throw new CustomException());

यह सब बहुत सुंदर नहीं निकला, इसलिए हम आगे बढ़ते हैं - ऑपरेटिंग सिस्टम और हैक्स के स्तर तक, जिसका उपयोग उत्पादन में नहीं किया जाना चाहिए।

सेह / वाहन

ध्यान दें कि प्रबंधित-अपवादों ने प्रबंधित और CLR के बीच उड़ान भरी, जबकि SEH-अपवाद CLR और Windows के बीच उड़ान भरते हैं।

SEH - संरचित अपवाद हैंडलिंग

विंडोज अपवाद हैंडलिंग इंजन
यूनिफॉर्म सॉफ्टवेयर और हार्डवेयर अपवाद हैंडलिंग
एसईएच के शीर्ष पर लागू सी # अपवाद

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

Rantime .NET SEH अपवादों के बारे में जानता है और उन्हें प्रबंधित अपवादों में परिवर्तित कर सकता है:

EXCEPTION_STACK_OVERFLOW -> क्रैश
EXCEPTION_ACCESS_VIOLATION -> AccessViolationException
EXCEPTION_ACCESS_VIOLATION -> NullReferenceException
EXCEPTION_INT_DIVIDE_BY_ZERO -> DivideByZeroException
अज्ञात SEH अपवाद -> SEHException

हम WinApi के माध्यम से SEH के साथ बातचीत कर सकते हैं।

 [DllImport("kernel32.dll")] static extern void RaiseException(uint dwExceptionCode, uint dwExceptionFlags, uint nNumberOfArguments,IntPtr lpArguments); // DivideByZeroException RaiseException(0xc0000094, 0, 0, IntPtr.Zero); // Stack overflow RaiseException(0xc00000fd, 0, 0, IntPtr.Zero);

वास्तव में, थ्रो कंस्ट्रक्शन SEH के माध्यम से भी काम करता है।

 throw -> RaiseException(0xe0434f4d, ...)

यहां यह ध्यान देने योग्य है कि सीएलआर-अपवाद कोड हमेशा समान होता है, इसलिए हम किस प्रकार का अपवाद फेंकते हैं, यह हमेशा संसाधित होता है।

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

हम अपने स्वयं के वेक्टर हैंडलर को ऑपरेटिंग सिस्टम और रनटाइम के बीच रख सकते हैं, जो SEH अपवादों को संभालेंगे और जब यह EXCEPTION_STACK_OVERFLOW से भिड़ता है, तो इसे बदल दें ताकि .NET रनटाइम प्रक्रिया को क्रैश न करे।

आप WinApi के माध्यम से VEH के साथ बातचीत कर सकते हैं:

 [DllImport("kernel32.dll", SetLastError = true)] static extern IntPtr AddVectoredExceptionHandler(IntPtr FirstHandler,  VECTORED_EXCEPTION_HANDLER VectoredHandler); delegate VEH PVECTORED_EXCEPTION_HANDLER(ref EXCEPTION_POINTERS exceptionPointers); public enum VEH : long { EXCEPTION_CONTINUE_SEARCH = 0, EXCEPTION_EXECUTE_HANDLER = 1, EXCEPTION_CONTINUE_EXECUTION = -1 } delegate VEH PVECTORED_EXCEPTION_HANDLER(ref EXCEPTION_POINTERS exceptionPointers); [StructLayout(LayoutKind.Sequential)] unsafe struct EXCEPTION_POINTERS { public EXCEPTION_RECORD* ExceptionRecord; public IntPtr Context; } delegate VEH PVECTORED_EXCEPTION_HANDLER(ref EXCEPTION_POINTERS exceptionPointers); [StructLayout(LayoutKind.Sequential)] unsafe struct EXCEPTION_RECORD { public uint ExceptionCode; ... }

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

 static unsafe VEH Handler(ref EXCEPTION_POINTERS e) { if (e.ExceptionRecord == null) return VEH. EXCEPTION_CONTINUE_SEARCH; var record = e. ExceptionRecord; if (record->ExceptionCode != ExceptionStackOverflow) return VEH. EXCEPTION_CONTINUE_SEARCH; record->ExceptionCode = 0x01234567; return VEH. EXCEPTION_EXECUTE_HANDLER; }

अब हम एक रैपर बनाते हैं जो हैंडलेशो विधि के रूप में एक वेक्टर हैंडलर स्थापित करता है, जो एक प्रतिनिधि में लेता है जो संभावित रूप से एक StackOverflowException (स्पष्टता के लिए कोड से गिर सकता है, WinA फ़ंक्शन फ़ंक्शन त्रुटियों को हैंडल नहीं करता है और वेक्टर हैंडलर को निकालता है)।

 HandleSO(() => InfiniteRecursion()) ; static T HandleSO<T>(Func<T> action) { Kernel32. AddVectoredExceptionHandler(IntPtr.Zero, Handler); Kernel32.SetThreadStackGuarantee(ref size); try { return action(); } catch (Exception e) when ((uint) Marshal. GetExceptionCode() == 0x01234567) {} return default(T); } HandleSO(() => InfiniteRecursion());

इसके अंदर, SetThreadStackGuarantee विधि का भी उपयोग किया जाता है। यह विधि StackOverflow प्रसंस्करण के लिए स्टैक स्थान रखता है।

इस तरह, हम अनंत पुनरावृत्ति के साथ एक विधि के आह्वान से बच सकते हैं। हमारी धारा काम करती रहेगी जैसे कि कुछ भी नहीं हुआ था, जैसे कि कोई अतिप्रवाह नहीं हुआ।

लेकिन अगर आप एक ही धागे में दो बार हैंडल को कहते हैं तो क्या होगा?

 HandleSO(() => InfiniteRecursion()); HandleSO(() => InfiniteRecursion());

और एक AccessViolationException होगी। स्टैक डिवाइस पर वापस।

ऑपरेटिंग सिस्टम स्टैक ओवरफ्लो का पता लगा सकता है। ढेर के शीर्ष पर एक विशेष पृष्ठ है जिसे गार्ड पृष्ठ ध्वज के साथ चिह्नित किया गया है। पहली बार जब यह पृष्ठ एक्सेस किया जाता है, तो एक और अपवाद होगा - STATUS_GUARD_PAGE_VIOLATION, और गार्ड पृष्ठ ध्वज पृष्ठ से हटा दिया जाएगा। यदि आप बस इस अतिप्रवाह को रोकते हैं, तो यह पृष्ठ अब स्टैक पर नहीं होगा - अगले ओवरफ्लो में, ऑपरेटिंग सिस्टम यह समझने में सक्षम नहीं होगा और स्टैक-पॉइंटर स्टैक के लिए आवंटित मेमोरी से परे जाएगा। परिणामस्वरूप, एक AccessViolationException उत्पन्न होगी। इसलिए आपको StackOverflow को संसाधित करने के बाद पृष्ठ के झंडे को पुनर्स्थापित करने की आवश्यकता है - ऐसा करने का सबसे आसान तरीका सी रनटाइम लाइब्रेरी (msvcrt.dll) से _resetstkoflw विधि का उपयोग करना है।

 [DllImport("msvcrt.dll")] static extern int _resetstkoflw();

इसी तरह से, आप विंडोज के तहत .NET कोर में एक AccessViolationException को पकड़ सकते हैं, जिससे प्रक्रिया क्रैश हो जाती है। इस स्थिति में, आपको उस क्रम को ध्यान में रखना होगा जिसमें वेक्टर हैंडलर को बुलाया जाता है और आपके हैंडलर को श्रृंखला की शुरुआत में सेट किया जाता है, क्योंकि .NET Core भी एक्सेसविलेजेशन को संसाधित करते समय VEH का उपयोग करता है। AddVectoredExceptionHandler फ़ंक्शन का पहला पैरामीटर उस ऑर्डर के लिए ज़िम्मेदार है, जिसमें हैंडलर कहा जाता है:

 Kernel32.AddVectoredExceptionHandler(FirstHandler: (IntPtr) 1, handler);

व्यावहारिक मुद्दों का अध्ययन करने के बाद, हम सामान्य परिणामों को संक्षेप में प्रस्तुत करते हैं:

अपवाद उतने सरल नहीं हैं जितने वे लगते हैं;
सभी अपवादों को एक ही तरह से नहीं संभाला जाता है;
गर्भपात के विभिन्न स्तरों पर अपवाद की हैंडलिंग होती है;
आप अपवाद हैंडलिंग प्रक्रिया में हस्तक्षेप कर सकते हैं और .NET रनटाइम को मूल रूप से इच्छित से अलग काम कर सकते हैं।

संदर्भ

→ रिपोर्ट से उदाहरण के साथ भंडार
→ - एडम Sitnik द्वारा - Dotnext 2016 मास्को असाधारण .NET में अपवाद है
→ DotNetBook: अपवाद
→ नेट इनसाइड आउट भाग 8 - हैंडलिंग स्टैक ओवरफ़्लो में सी # VEH साथ अपवाद है अवरोधन StackOverflow करने के लिए एक और तरीका है -।

22-23 नवंबर को, यूजीन DotNext 2018 मास्को में एक रिपोर्ट "सिस्टम मेट्रिक्स: कलेक्टिंग पिट्स " के साथ बात करेंगे । जेफरी रिक्टर, ग्रेग यंग, पावेल योसिफोविच और अन्य समान रूप से दिलचस्प वक्ता मास्को में आएंगे। रिपोर्टों के विषय यहाँ देखे जा सकते हैं , और यहाँ टिकट खरीद सकते हैं । अब सम्मिलित हों!

.NET में विशेष अपवाद और उन्हें कैसे तैयार किया जाए