असाधारण स्थितियों: 4 का भाग 1

परिचय

यह अपवादों के बारे में बात करने का समय है या, असाधारण स्थितियों के बारे में। शुरू करने से पहले, आइए परिभाषा देखें। एक असाधारण स्थिति क्या है?

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

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

struct Number { public static Number Parse(string source) { // ... if(!parsed) { throw new ParsingException(); } // ... } public static bool TryParse(string source, out Number result) { // .. return parsed; } } 

यह उदाहरण थोड़ा अजीब लगता है, और यह एक कारण के लिए है। इसमें दिखने वाली समस्याओं के महत्व को दर्शाने के लिए मैंने इस कोड को थोड़ा कृत्रिम बना दिया। सबसे पहले, Parse विधि को देखें। इसे अपवाद क्यों फेंकना चाहिए?

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

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

विधि का दूसरा संस्करण इनपुट डेटा के साथ कुछ समस्याओं का संकेत दे सकता है: यहां वापसी मूल्य boolean जो विधि के सफल निष्पादन को इंगित करता है। इस पद्धति को किसी भी समस्या को इंगित करने के लिए अपवादों का उपयोग करने की आवश्यकता नहीं है: वे सभी false रिटर्न मूल्य द्वारा कवर किए गए हैं।

अवलोकन

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

हम देख सकते हैं कि बड़ी .NET फ्रेमवर्क के अंदर दो दुनियाएँ हैं: सब कुछ जो CLR से संबंधित है और जो कुछ भी नहीं करता है, जिसमें विंडोज में दिखाई देने वाली सभी संभावित त्रुटियाँ और असुरक्षित दुनिया के अन्य हिस्से शामिल हैं।

• संरचित अपवाद हैंडलिंग (SEH) एक मानक तरीका है जो Windows अपवादों को संभालता है। जब unsafe तरीकों को बुलाया जाता है और अपवादों को फेंक दिया जाता है, तो असुरक्षित <-> CLR रूपांतरण दोनों दिशाओं में होता है: असुरक्षित से CLR और पिछड़े में। ऐसा इसलिए है क्योंकि CLR एक असुरक्षित विधि कह सकता है जो बदले में CLR विधि कह सकता है।
• वेक्टरेड एक्सेप्शन हैंडलिंग (वीईएच) एसईएच की एक जड़ है और आपको अपने हैंडलर को उन जगहों पर रखने की अनुमति देता है जहां अपवाद फेंके जा सकते हैं। विशेष रूप से, यह FirstChanceException रखने के लिए उपयोग किया जाता है।
• COM + अपवाद तब प्रकट होते हैं जब किसी समस्या का स्रोत COM घटक होता है। इस स्थिति में, COM और .NET विधि के बीच एक परत को COM त्रुटि को .NET अपवाद में बदलना होगा।
• और, ज़ाहिर है, HRESULT के लिए रैपर। उन्हें एक WinAPI मॉडल परिवर्तित करने के लिए पेश किया जाता है (एक त्रुटि कोड रिटर्न मान में समाहित है, जबकि रिटर्न मानों को विधि मापदंडों का उपयोग करके प्राप्त किया जाता है) अपवादों के मॉडल में क्योंकि यह एक अपवाद है जो .NET के लिए मानक है।

दूसरी ओर, सीएलआई से ऊपर की भाषाएं हैं जिनमें से प्रत्येक में अपवादों को संभालने के लिए अधिक या कम कार्य हैं। उदाहरण के लिए, हाल ही में VB.NET या F # में C # में मौजूद फिल्टर की संख्या में व्यक्त की जाने वाली एक समृद्ध अपवाद हैंडलिंग कार्यक्षमता थी।

रिटर्न कोड बनाम। अपवाद

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

मान लें कि त्रुटियों से निपटने के लिए सभी तरीकों में इंटरफेस है। तब सभी तरीके इस तरह दिखेंगे:

 public bool TryParseInteger(string source, out int result); public DialogBoxResult OpenDialogBox(...); public WebServiceResult IWebService.GetClientsList(...); public class DialogBoxResult : ResultBase { ... } public class WebServiceResult : ResultBase { ... } 

और उनका उपयोग इस तरह दिखेगा:

 public ShowClientsResult ShowClients(string group) { if(!TryParseInteger(group, out var clientsGroupId)) return new ShowClientsResult { Reason = ShowClientsResult.Reason.ParsingFailed }; var webResult = _service.GetClientsList(clientsGroupId); if(!webResult.Successful) { return new ShowClientsResult { Reason = ShowClientsResult.Reason.ServiceFailed, WebServiceResult = webResult }; } var dialogResult = _dialogsService.OpenDialogBox(webResult.Result); if(!dialogResult.Successful) { return new ShowClientsResult { Reason = ShowClientsResult.Reason.DialogOpeningFailed, DialogServiceResult = dialogResult }; } return ShowClientsResult.Success(); } 

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

कोई विधि किसी समस्या की रिपोर्ट कैसे कर सकती है? यह त्रुटियों की रिपोर्टिंग के लिए एक इंटरफ़ेस का उपयोग करके कर सकता है। उदाहरण के लिए, TryParseInteger पद्धति में इस तरह के इंटरफ़ेस को एक रिटर्न मान द्वारा दर्शाया गया है: यदि सब कुछ ठीक है, तो विधि true वापस आ जाएगी। यदि यह ठीक नहीं है, तो यह false होगा। हालांकि, यहां एक नुकसान है: वास्तविक मूल्य को out int result पैरामीटर के माध्यम out int result लौटाया जाता out int result । नुकसान यह है कि एक तरफ रिटर्न वैल्यू तार्किक रूप से है और धारणा के अनुसार out पैरामीटर की तुलना में अधिक "रिटर्न वैल्यू" सार है। दूसरी तरफ, हम हमेशा त्रुटियों के बारे में परवाह नहीं करते हैं। पार्सिंग एक सेवा से आता है जो इस स्ट्रिंग को उत्पन्न करता है, हमें त्रुटियों के लिए इसकी जांच करने की आवश्यकता नहीं है: स्ट्रिंग हमेशा पार्स करने के लिए सही और अच्छी होगी। हालांकि, मान लीजिए कि हम विधि का एक और कार्यान्वयन लेते हैं:

 public int ParseInt(string source); 

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

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

अंत में संक्षेप में पकड़ने की कोशिश करो

एक try ब्लॉक एक अनुभाग को शामिल करता है जहां एक प्रोग्रामर एक महत्वपूर्ण स्थिति प्राप्त करने की उम्मीद करता है जिसे बाहरी कोड द्वारा एक आदर्श के रूप में माना जाता है। दूसरे शब्दों में, यदि कुछ कोड कुछ नियमों के आधार पर अपनी आंतरिक स्थिति को असंगत मानते हैं और एक अपवाद को फेंक देते हैं, तो एक बाहरी प्रणाली, जिसमें एक ही स्थिति का व्यापक दृष्टिकोण होता है, catch ब्लॉक का उपयोग करके इस अपवाद को पकड़ सकता है और एप्लिकेशन कोड के निष्पादन को सामान्य कर सकता है । इस प्रकार, आप कोड के इस खंड में अपवादों को पकड़ कर उन्हें वैध करते हैं । मुझे लगता है कि यह एक महत्वपूर्ण विचार है, जो सभी मामले को पकड़ने के लिए प्रतिबंध को सही ठहराता है try-catch(Exception ex){ ...} अपवाद केवल मामले में ।

इसका मतलब यह नहीं है कि अपवादों को पकड़ना कुछ विचारधाराओं का विरोध करता है। मैं कहता हूं कि आपको केवल उन त्रुटियों को पकड़ना चाहिए जो आप किसी विशेष खंड से अपेक्षा करते हैं। उदाहरण के लिए, आप ArgumentException से विरासत में लिए गए सभी प्रकार के अपवादों की अपेक्षा नहीं कर सकते हैं या आप NullReferenceException प्राप्त नहीं कर सकते, क्योंकि अक्सर इसका मतलब यह है कि समस्या आपके कोड में एक के बजाय एक है। लेकिन यह उम्मीद करना उचित है कि आप एक इच्छित फ़ाइल नहीं खोल पाएंगे। यहां तक ​​कि अगर आप 200% सुनिश्चित हैं कि आप सक्षम होंगे, तो जांच करना न भूलें।

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

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

क्या वास्तव में कमी सी # एक fault ब्लॉक है जो जब भी कोई त्रुटि होती है सक्रिय होती है। यह स्टेरॉयड पर finally पसंद है। यदि हमारे पास यह था, तो हम उदाहरण के लिए, असाधारण स्थितियों को लॉग करने के लिए एक एकल प्रविष्टि बिंदु बना सकते हैं:

 try { //... } fault exception { _logger.Warn(exception); } 

एक और बात जो मुझे इस परिचय में छूनी चाहिए वह है अपवाद फ़िल्टर। यह .NET प्लेटफ़ॉर्म पर एक नई सुविधा नहीं है, लेकिन C # डेवलपर्स इसके लिए नए हो सकते हैं: अपवाद फ़िल्टरिंग केवल v में दिखाई दिया। 6.0। फिल्टर को एक ऐसी स्थिति को सामान्य करना चाहिए जब एक ही प्रकार का अपवाद हो जो कई प्रकार की त्रुटियों को जोड़ती है। जब हम किसी विशेष परिदृश्य से निपटना चाहते हैं तो हमें इसमें मदद करनी चाहिए, लेकिन पहले त्रुटियों के पूरे समूह को पकड़ना होगा और बाद में उन्हें फ़िल्टर करना होगा। बेशक, मेरा मतलब निम्न प्रकार का कोड है:

 try { //... } catch (ParserException exception) { switch(exception.ErrorCode) { case ErrorCode.MissingModifier: // ... break; case ErrorCode.MissingBracket: // ... break; default: throw; } } 

ठीक है, अब हम इस कोड को फिर से लिख सकते हैं:

 try { //... } catch (ParserException exception) when (exception.ErrorCode == ErrorCode.MissingModifier) { // ... } catch (ParserException exception) when (exception.ErrorCode == ErrorCode.MissingBracket) { // ... } 

यहां सुधार switch निर्माण की कमी में नहीं है। मेरा मानना ​​है कि यह नया निर्माण कई चीजों में बेहतर है:

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

कई स्रोतों का कहना है कि इस कोड की ख़ासियत यह है कि फ़िल्टर अनियंत्रित होने से पहले होता है। आप इसे उन स्थितियों में देख सकते हैं जब किसी अपवाद को उस स्थान के बीच सामान्य रूप से छोड़कर कोई अन्य कॉल नहीं होता है और जिस स्थान पर फ़िल्टरिंग चेक होता है।

 static void Main() { try { Foo(); } catch (Exception ex) when (Check(ex)) { ; } } static void Foo() { Boo(); } static void Boo() { throw new Exception("1"); } static bool Check(Exception ex) { return ex.Message == "1"; } 

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

क्रमबद्धता

चलिए निम्नलिखित कोड को चलाने के परिणामों को देखते हुए शुरू करते हैं (मैंने दो एप्लिकेशन डोमेन के बीच की सीमा में एक कॉल के हस्तांतरण को जोड़ा)।

  class Program { static void Main() { try { ProxyRunner.Go(); } catch (Exception ex) when (Check(ex)) { ; } } static bool Check(Exception ex) { var domain = AppDomain.CurrentDomain.FriendlyName; // -> TestApp.exe return ex.Message == "1"; } public class ProxyRunner : MarshalByRefObject { private void MethodInsideAppDomain() { throw new Exception("1"); } public static void Go() { var dom = AppDomain.CreateDomain("PseudoIsolated", null, new AppDomainSetup { ApplicationBase = AppDomain.CurrentDomain.BaseDirectory }); var proxy = (ProxyRunner) dom.CreateInstanceAndUnwrap(typeof(ProxyRunner).Assembly.FullName, typeof(ProxyRunner).FullName); proxy.MethodInsideAppDomain(); } } } 

हम देख सकते हैं कि फ़िल्टर करने से पहले स्टैक अनरोलिंग होता है। चलिए स्क्रीनशॉट देखते हैं। पहले अपवाद की पीढ़ी से पहले लिया जाता है:

दूसरा इसके बाद है:

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

 [StructLayout(LayoutKind.Explicit)] class Cast { [FieldOffset(0)] public Exception Exception; [FieldOffset(0)] public object obj; } static void Main() { try { ProxyRunner.Go(); Console.ReadKey(); } catch (RuntimeWrappedException ex) when (ex.WrappedException is Program) { ; } } static bool Check(Exception ex) { var domain = AppDomain.CurrentDomain.FriendlyName; // -> TestApp.exe return ex.Message == "1"; } public class ProxyRunner : MarshalByRefObject { private void MethodInsideAppDomain() { var x = new Cast {obj = new Program()}; throw x.Exception; } public static void Go() { var dom = AppDomain.CreateDomain("PseudoIsolated", null, new AppDomainSetup { ApplicationBase = AppDomain.CurrentDomain.BaseDirectory }); var proxy = (ProxyRunner)dom.CreateInstanceAndUnwrap(typeof(ProxyRunner).Assembly.FullName, typeof(ProxyRunner).FullName); proxy.MethodInsideAppDomain(); } } 

C # कोड के लिए किसी भी प्रकार के अपवाद को फेंक सकता है (मैं आपको MSIL के साथ अत्याचार नहीं करना चाहता) मैंने इस उदाहरण में एक चाल चल कर एक गैर-प्रकार के लिए एक कास्टिंग डाली, इसलिए हम किसी भी प्रकार के अपवाद को फेंक सकते हैं, लेकिन अनुवादक सोचेंगे कि हम Exception प्रकार का उपयोग करते हैं। हम Program प्रकार का एक उदाहरण बनाते हैं, जो सुनिश्चित करने के लिए अनुक्रमणीय नहीं है, और इस प्रकार का कार्यभार के रूप में उपयोग करके एक अपवाद फेंक देते हैं। अच्छी खबर यह है कि आपको RuntimeWrappedException गैर-अपवाद अपवादों के लिए एक रैपर मिलता है जो हमारे Program प्रकार ऑब्जेक्ट के एक उदाहरण को अंदर संग्रहीत करेगा और हम इस अपवाद को पकड़ने में सक्षम होंगे। हालांकि, बुरी खबर है जो हमारे विचार का समर्थन करती है: कॉलिंग proxy.MethodInsideAppDomain(); SerializationException उत्पन्न करेगा:

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

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

डोमेन के बीच क्रमबद्ध ऑब्जेक्ट को स्थानांतरित करने से आपको मेमोरी में कुछ परिसीमन करते हुए एक डोमेन से दूसरे डोमेन में ऑब्जेक्ट की पूरी कॉपी मिलती है। हालाँकि, यह परिसीमन काल्पनिक है। इसका उपयोग केवल उन प्रकारों के लिए किया जाता है जो Shared AppDomain में नहीं हैं। इस प्रकार, यदि आप एक अपवाद के रूप में कुछ गैर-धारावाहिक हैं, लेकिन Shared AppDomain , आपको क्रमांकन की त्रुटि नहीं मिलेगी (हम Program बजाय Action फेंकने की कोशिश कर सकते हैं)। हालांकि, इस मामले में स्टैक अनिरोलिंग वैसे भी होगा: चूंकि दोनों वेरिएंट को मानक तरीके से काम करना चाहिए। ताकि किसी को भ्रम न हो।

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

इसके अलावा, अगर आप हमें धन्यवाद देना चाहते हैं, तो आप सबसे अच्छा तरीका यह कर सकते हैं कि हमें गितुब पर एक स्टार देना है या रिपॉजिटरी को फोर्क करना है github / sidristij / dotnetbook ।