[डॉटनेटबुक] अपवाद घटनाओं और कैसे खरोंच से StackOverflow और ExecutionEngineException प्राप्त करने के लिए

अपवाद घटनाएँ

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

 try { // ... } catch { // do nothing, just to make code call more safe } 

ऐसी स्थिति में, यह पता चल सकता है कि कोड निष्पादन अब उतना सुरक्षित नहीं है जितना दिखता है, लेकिन हमारे पास कोई भी समस्या नहीं है। दूसरा विकल्प यह है कि आवेदन कुछ को दबा देता है, यहां तक ​​कि कानूनी, अपवाद। और परिणाम - यादृच्छिक स्थान पर निम्न अपवाद के कारण एप्लिकेशन भविष्य में प्रतीत होने वाली यादृच्छिक त्रुटि से क्रैश हो जाएगा। यहाँ मैं एक विचार रखना चाहूंगा कि इस त्रुटि की पृष्ठभूमि क्या थी। इस स्थिति के लिए घटनाओं का कोर्स क्या है। और इसे संभव बनाने का एक तरीका अतिरिक्त घटनाओं का उपयोग करना है जो असाधारण स्थितियों से संबंधित हैं: AppDomain.FirstChanceException और AppDomain.UnhandledException ।

टिप्पणी

हैबे पर प्रकाशित अध्याय अद्यतन नहीं है और, शायद, पहले से ही थोड़ा पुराना है। और इसलिए, कृपया हाल के पाठ के लिए मूल पर जाएं:

• सीएलआर बुक: गिटहब, सामग्री की तालिका
• सीएलआर बुक: गिटहब, चैप्टर
• 0.5.2 पुस्तकें, PDF: GitHub रिलीज़ जारी करें

वास्तव में, जब आप "एक अपवाद फेंकते हैं", तो कुछ आंतरिक Throw सबसिस्टम की सामान्य विधि को कहा जाता है, जो स्वयं अंदर निम्नलिखित कार्य करता है:

• AppDomain.FirstChanceException फेंकता है
• हैंडलर की श्रृंखला में फिल्टर के मिलान के लिए खोजें
• स्टैक को वांछित फ्रेम में पूर्व-रोल करने के लिए हैंडलर का कारण बनता है।
• यदि कोई हैंडलर नहीं मिला, तो AppDomain.UnhandledException को AppDomain.UnhandledException , उस थ्रेड को क्रैश करते हुए जिसमें अपवाद हुआ।

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

दूसरी बात "ऐशोर" के बारे में है कि इन घटनाओं को Thread नहीं, बल्कि AppDomain । आखिरकार, यदि आप तर्क का पालन करते हैं, तो अपवाद कहां पैदा होते हैं? कमांड निष्पादन के प्रवाह में। यानी वास्तव में Thread । तो डोमेन को समस्या क्यों है? इसका उत्तर बहुत सरल है: किन स्थितियों के लिए AppDomain.FirstChanceException और AppDomain.UnhandledException ? अन्य चीजों के बीच - प्लगइन्स के लिए सैंडबॉक्स बनाने के लिए। यानी स्थितियों के लिए जब एक निश्चित AppDomain जो PartialTrust के लिए कॉन्फ़िगर किया गया है। इस AppDomain के अंदर कुछ भी हो सकता है: थ्रेड्स किसी भी समय वहां बनाए जा सकते हैं, या थ्रेडपूल से मौजूदा का उपयोग किया जा सकता है। तब यह पता चलता है कि हम इस प्रक्रिया से बाहर हैं (हमने वह कोड नहीं लिखा है), हम आंतरिक प्रवाह की घटनाओं की सदस्यता नहीं ले सकते। सिर्फ इसलिए कि हमें पता नहीं है कि वहाँ क्या प्रवाह बनाए गए थे। लेकिन हमारे पास एक AppDomain होने की गारंटी है जो सैंडबॉक्स और हमारे पास मौजूद लिंक को व्यवस्थित करता है।

इसलिए, वास्तव में, हमें दो क्षेत्रीय घटनाओं के साथ प्रदान किया जाता है: कुछ ऐसा हुआ जो माना नहीं गया था ( FirstChanceExecption ) और "सब कुछ खराब है", किसी ने अपवाद को नहीं संभाला: यह प्रदान नहीं किया गया था। इसलिए, कमांड निष्पादन का प्रवाह समझ में नहीं आता है और इसे ( Thread ) भेज दिया जाएगा।

इन घटनाओं के होने से क्या प्राप्त हो सकता है और यह क्यों बुरा है कि डेवलपर्स इन घटनाओं को दरकिनार करते हैं?

AppDomain.FirstChanceException

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

लेकिन आइए सबसे पहले इसके प्रसंस्करण के एक सरल सिंथेटिक उदाहरण को देखें:

 void Main() { var counter = 0; AppDomain.CurrentDomain.FirstChanceException += (_, args) => { Console.WriteLine(args.Exception.Message); if(++counter == 1) { throw new ArgumentOutOfRangeException(); } }; throw new Exception("Hello!"); } 

इस कोड के बारे में क्या उल्लेखनीय है? जहां भी कुछ कोड एक अपवाद फेंकता है, पहली चीज जो होती है वह कंसोल में प्रवेश करती है। यानी यहां तक ​​कि अगर आप भूल जाते हैं या कुछ प्रकार के अपवादों को संभालने की कल्पना नहीं कर सकते हैं, तो यह उस घटना लॉग में दिखाई देगा जो आप आयोजित कर रहे हैं। दूसरा एक आंतरिक अपवाद को फेंकने के लिए कुछ अजीब स्थिति है। बात यह है कि FirstChanceException हैंडलर के अंदर आप केवल एक अपवाद को नहीं फेंक सकते और फेंक सकते हैं। बल्कि, यहां तक ​​कि: FirstChanceException हैंडलर के अंदर, आप कम से कम किसी भी अपवाद को फेंकने में सक्षम नहीं हैं। यदि आप ऐसा करते हैं, तो दो संभावित घटनाएं हैं। सबसे पहले, अगर कोई नहीं थे if(++counter == 1) स्थिति, तो हमें एक सर्व-नया ArgumentOutOfRangeException लिए अनंत FirstChanceException । इसका क्या मतलब है? इसका मतलब यह है कि एक निश्चित स्तर पर हमें एक StackOverflowException : throw new Exception("Hello!") FirstChanceException throw new Exception("Hello!") FirstChanceException , CLR थ्रो विधि को फेंकता है, जो FirstChanceException फेंकता है, जो पहले से ही FirstChanceException लिए Throw फेंकता है और फिर पुन: हो जाता है। दूसरा विकल्प - हमने counter स्थिति का उपयोग करके पुनरावृत्ति की गहराई से खुद का बचाव किया। यानी इस मामले में, हम केवल एक बार एक अपवाद फेंक देते हैं। परिणाम अप्रत्याशित से अधिक है: हमें एक अपवाद मिलता है जो वास्तव में Throw निर्देश के अंदर काम करता है। और इस प्रकार की त्रुटि के लिए सबसे उपयुक्त क्या है? ECMA-335 के अनुसार, यदि एक निर्देश को एक अपवाद में फेंक दिया गया था, तो एक ExecutionEngineException को फेंक दिया जाना चाहिए! लेकिन हम इस असाधारण स्थिति को संभालने में सक्षम नहीं हैं। यह आवेदन से एक पूर्ण दुर्घटना की ओर जाता है। हमारे पास सुरक्षित प्रसंस्करण विकल्प क्या हैं?

पहली बात जो दिमाग में आती है, वह FirstChanceException हैंडलर के पूरे कोड पर FirstChanceException try-catch ब्लॉक सेट करना है:

 void Main() { var fceStarted = false; var sync = new object(); EventHandler<FirstChanceExceptionEventArgs> handler; handler = new EventHandler<FirstChanceExceptionEventArgs>((_, args) => { lock (sync) { if (fceStarted) { //     - ,        -      , //   try  . Console.WriteLine($"FirstChanceException inside FirstChanceException ({args.Exception.GetType().FullName})"); return; } fceStarted = true; try { //     . ,   Console.WriteLine(args.Exception.Message); throw new ArgumentOutOfRangeException(); } catch (Exception exception) { //       Console.WriteLine("Success"); } finally { fceStarted = false; } } }); AppDomain.CurrentDomain.FirstChanceException += handler; try { throw new Exception("Hello!"); } finally { AppDomain.CurrentDomain.FirstChanceException -= handler; } } OUTPUT: Hello! Specified argument was out of the range of valid values. FirstChanceException inside FirstChanceException (System.ArgumentOutOfRangeException) Success !Exception: Hello! 

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

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

 static void Main() { using (ApplicationLogger.Go(AppDomain.CurrentDomain)) { throw new Exception("Hello!"); } } public class ApplicationLogger : MarshalByRefObject { ConcurrentQueue<Exception> queue = new ConcurrentQueue<Exception>(); CancellationTokenSource cancellation; ManualResetEvent @event; public void LogFCE(Exception message) { queue.Enqueue(message); } private void StartThread() { cancellation = new CancellationTokenSource(); @event = new ManualResetEvent(false); var thread = new Thread(() => { while (!cancellation.IsCancellationRequested) { if (queue.TryDequeue(out var exception)) { Console.WriteLine(exception.Message); } Thread.Yield(); } @event.Set(); }); thread.Start(); } private void StopAndWait() { cancellation.Cancel(); @event.WaitOne(); } public static IDisposable Go(AppDomain observable) { var dom = AppDomain.CreateDomain("ApplicationLogger", null, new AppDomainSetup { ApplicationBase = AppDomain.CurrentDomain.BaseDirectory, }); var proxy = (ApplicationLogger)dom.CreateInstanceAndUnwrap(typeof(ApplicationLogger).Assembly.FullName, typeof(ApplicationLogger).FullName); proxy.StartThread(); var subscription = new EventHandler<FirstChanceExceptionEventArgs>((_, args) => { proxy.LogFCE(args.Exception); }); observable.FirstChanceException += subscription; return new Subscription(() => { observable.FirstChanceException -= subscription; proxy.StopAndWait(); }); } private class Subscription : IDisposable { Action act; public Subscription (Action act) { this.act = act; } public void Dispose() { act(); } } } 

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

AppDomain.UnhandledException

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

मान लीजिए हमारे पास एक पुस्तकालय है, जिसे थ्रेड बनाने और इन थ्रेड्स में किसी प्रकार के तर्क को लागू करने की आवश्यकता है। हम, इस पुस्तकालय के उपयोगकर्ताओं के रूप में, केवल एपीआई कॉल की गारंटी के साथ-साथ त्रुटि संदेश प्राप्त करने में रुचि रखते हैं। यदि पुस्तकालय इसके बारे में सूचित किए बिना धाराओं को क्रैश कर देगा, तो यह हमारी बहुत मदद नहीं कर सकता है। इसके अलावा, धारा के ढहने से AppDomain.UnhandledException संदेश जाएगा, जिसमें इस बारे में कोई जानकारी नहीं है कि कौन सी विशेष धारा इसके किनारे पर है। अगर हम अपने कोड के बारे में बात कर रहे हैं, तो दुर्घटनाग्रस्त धारा भी हमारे लिए उपयोगी नहीं है। किसी भी मामले में, मैं इसके लिए आवश्यकता को पूरा नहीं करता था। हमारा कार्य त्रुटियों को सही ढंग से संसाधित करना है, त्रुटि लॉग में उनकी घटना के बारे में जानकारी भेजना और प्रवाह को सही ढंग से समाप्त करना है। यानी अनिवार्य रूप से उस विधि को लपेटें जिसके साथ धागा ट्राइ try-catch में शुरू होता है:

  ThreadPool.QueueUserWorkitem(_ => { using(Disposables aggregator = ...){ try { // do work here, plus: aggregator.Add(subscriptions); aggregator.Add(dependantResources); } catch (Exception ex) { logger.Error(ex, "Unhandled exception"); } } }); 

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

पूरी किताब का लिंक

• सीएलआर बुक: गिटहब
• 0.5.0 पुस्तकें, PDF: GitHub रिलीज़ जारी करें