🥫 🕘 🤦🏿 बहिष्करण सुरक्षा गारंटी 🧕🏽 ♋️ 🎸

एरर हैंडलिंग में त्रुटियां त्रुटियों का सबसे आम स्रोत हैं।

इस लेख को लिखते समय दिमाग में आया बुलिश

सी # में प्रोग्रामिंग करते समय उपयोग करने के लिए बेहतर क्या है के बारे में मुख्य लड़ाइयों - प्रसंस्करण के लिए अपवाद या रिटर्न कोड दूर अतीत (*) में चले गए हैं, लेकिन एक अलग तरह की लड़ाई अभी भी कम नहीं हुई है: हाँ, ठीक है, हम अपवाद हैंडलिंग पर बस गए, लेकिन हम उन्हें कैसे "सही ढंग से" संभालते हैं?

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

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

तीन तरह की गारंटी

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

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

मूल वारंटी

प्रारंभिक परिभाषा : " अपवादों की स्थिति में, संसाधनों का रिसाव नहीं होगा ।"

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

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

सख्त वारंटी

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

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

कोई बहिष्करण गारंटी नहीं

अपवादों की अनुपस्थिति की गारंटी निम्न के लिए कम है: " किसी भी परिस्थिति में फ़ंक्शन अपवाद नहीं छोड़ेंगे "।

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

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

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

अब कुछ उदाहरण देखते हैं।

मूल वारंटी के उल्लंघन के उदाहरण हैं

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

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

आइए एक उदाहरण देखें:

// , class DisposableA : IDisposable { public void Dispose() {} } // class DisposableB : IDisposable { public DisposableB() { disposableA = new DisposableA(); throw new Exception( "OOPS!" ); } public void Dispose() {} private DisposableA disposableA; } // - using ( var disposable = new DisposableB()) { // ! Dispose // DisposableB, DisposableA } * This source code was highlighted with Source Code Highlighter .

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

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

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

class Base : IDisposable { public Base() { // } public void Dispose() {} } class Derived : Base, IDisposable { public Derived( object data) { if (data == null ) throw new ArgumentNullException( "data" ); // OOPS!! } } // - using ( var derived = new Derived( null )) {} * This source code was highlighted with Source Code Highlighter .

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

बेस क्लास के अलावा, फील्ड इनिशियलाइज़र एक समान मज़ाक खेल सकते हैं जब खेतों में से एक का कंस्ट्रक्टर अपवाद फेंक सकता है:

class ComposedDisposable : IDisposable { public void Dispose() {} private readonly DisposableA disposableA = new DisposableA(); // , DisposableB ? OOPS!! private readonly DisposableB disposableB = new DisposableB(); } * This source code was highlighted with Source Code Highlighter .

इस मामले में, यदि डिस्पोजेबल वर्ग के निर्माणकर्ता ने डिस्पोजेबल फ़ील्ड को शुरू करते समय एक अपवाद फेंकता है , तो इसे पकड़ना और पहले से ही कैप्चर किए गए संसाधनों को जारी करना असंभव होगा। C ++ में, अपवाद सूची को पकड़ने वाली सूची ( अपवाद और सदस्य प्रारंभ देखें ) में ऐसा कुछ है, लेकिन C # में ऐसी कोई संभावना नहीं है, इसलिए इस स्थिति से केवल एक ही रास्ता है: इसे अनुमति न देने का प्रयास करें।

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

अपवादों की सख्त गारंटी का एक उदाहरण। ऑब्जेक्ट इनिशियलाइज़र और संग्रह आरम्भक

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

ऑब्जेक्ट्स और कलेक्शंस (ऑब्जेक्ट इनिशलाइज़र और कलेक्शन इनिशलाइज़र) का इनिलाइज़र किसी ऑब्जेक्ट की लिस्ट बनाने या कलेक्शन करने की एटोमेसी को सुनिश्चित करता है या कलेक्शंस को लिस्ट करता है। आइए निम्नलिखित उदाहरण देखें।

class Person { public string FirstName { get ; set ; } public string LastName { get ; set ; } public int Age { get ; set ; } } var person = new Person { FirstName = "Bill" , LastName = "Gates" , Age = 55, }; * This source code was highlighted with Source Code Highlighter .

पहली नज़र में, ऐसा लग सकता है कि यह निम्नलिखित के लिए सिंटैक्टिक चीनी है:

var person = new Person(); person.FirstName = "Bill" ; person.LastName = "Gates" ; person.Age = 55; * This source code was highlighted with Source Code Highlighter .

हालांकि, वास्तव में, जब ऑब्जेक्ट इनिशियलाइज़र कहा जाता है, तो एक अस्थायी चर बनाया जाता है, फिर इस विशेष चर के गुणों को बदल दिया जाता है, और उसके बाद ही इसे नई वस्तु को सौंपा जाता है :

var tmpPerson = new Person(); tmpPerson.FirstName = "Bill" ; tmpPerson.LastName = "Gates" ; tmpPerson.Age = 55; var person = tmpPerson; * This source code was highlighted with Source Code Highlighter .

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

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

निष्कर्ष

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

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

निष्कर्ष में, हम निम्नलिखित कह सकते हैं: अपवादों की सुरक्षा के लिए गारंटी एक रामबाण नहीं है, लेकिन विश्वसनीय अनुप्रयोगों के निर्माण के लिए एक उत्कृष्ट आधार है ।

----------------------

(*) वास्तव में, एक साधारण कारण के लिए कोई भी "गर्म" बहस नहीं थी: आप बिना किसी से निपटने के लिए .Net मंच पर कार्यक्रम नहीं कर सकते। इस तरह की बहसें प्रासंगिक हैं, उदाहरण के लिए, सी ++ भाषा में, खासकर जब यह निम्न-स्तरीय प्रोग्रामिंग की बात आती है।

(**) सामान्य तौर पर, किसी को हमेशा अपरिवर्तनीय संरक्षण की आवश्यकता नहीं होती है; आमतौर पर, आवधिक "पहले" और "बाद में" कॉल करने के लिए खुली विधि की आवश्यकता होती है, लेकिन बंद पद्धति के लिए कॉल के बाद इसे बचाने के लिए आवश्यक नहीं है, जो कार्य का केवल "भाग" करता है।

(***) यह बहुत ही हास्यास्पद लग सकता है कि अधिक परिष्कृत भाषा जैसे कि C # कुछ ऐसा नहीं कर सकती है जो पुराना C ++ करता है, लेकिन यह वास्तव में है। आइए, एक उदाहरण के रूप में, C # से C ++ तक पहले चर्चा किए गए कोड को फिर से लिखें:

class Resource1 { public : Resource1() { // , - // } ~Resource1() { // } }; class Resource2 { public : Resource2() { // resource1_ throw std::exception( "Yahoo!" ); } private : Resource1 resource1_; }; // - Resource2 Resource2 resource2; * This source code was highlighted with Source Code Highlighter .

जैसा कि पहले सी ++ (सी # के विपरीत) में पहले उल्लेख किया गया है, जब एक अपवाद को क्लास कंस्ट्रक्टर में फेंक दिया जाता है, तो पहले से ही निर्मित फ़ील्ड (यानी, सबजेक्ट) के विध्वंसक स्वचालित रूप से कहलाएंगे। इसका मतलब है कि इस मामले में, रिसोर्स 1 ऑब्जेक्ट के डिस्ट्रक्टर को कॉल अपने आप हो जाएगा और रिसोर्स लीक नहीं होगा।

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

वैसे, हर्ब सटर ने अपने लेख में एक बार पहले ही इस बारे में बात की थी: "सी + +, सी # और जावा में कंस्ट्रक्टर एक्सेप्शन" ।

(****) हो सकता है कि मुझे पहले से ही इन नोटों के साथ मिल गया हो, लेकिन यह काफी महत्वपूर्ण है और ऐसा लगता है, यह एक तरह से है। वे अक्सर साक्षात्कार में इस तरह के उदाहरण को सेट करना पसंद करते हैं, इसलिए अब, मेरे पाठकों को इसका सही उत्तर पता है!

(*****) इस लेख में कहा गया सब कुछ केवल तुल्यकालिक अपवादों पर लागू होता है, क्योंकि "अतुल्यकालिक" अपवादों की सुसंगत घटना की गारंटी देना लगभग असंभव है, जैसे कि OutOfMemoryException या ThreadAbortException । यहाँ सबूत के लिए: " थ्रेड के खतरों पर। एक विधि। "

बहिष्करण सुरक्षा गारंटी