सी # अपवाद हैंडलिंग तंत्र

Question

द्वारा Win32 अपवाद क्यों नहीं पकड़ा गया है मेरे पास एक Winforms एप्लिकेशन है। Winforms प्रोग्राम.cs से शुरू होते हैं जहां हमारे पास मुख्य() परिभाषित होता है। मैंने इस कोड को ट्राई-कैच ब्लॉक में रखा है।

[STAThread] 
    static void Main() 
    { 
     try 
     { 
      Application.EnableVisualStyles(); 
      Application.SetCompatibleTextRenderingDefault(false); 
      Application.Run(new frmSplash()); 
     } 
     catch (Exception ex) 
     { 
      MessageBox.Show(ex.Message); 
      if (ex.InnerException != null) 
      { 
       MessageBox.Show(ex.InnerException.ToString()); 
      } 
     } 
    } 

जब भी कोई Win32 अपवाद नहीं है, इस तंत्र विफल रहता है और बिना क्रिया का अपवाद संदेश फेंक दिया और अनुप्रयोग क्रैश हो जाता है।
मेरे पास इस कोड के बारे में 2 प्रश्न हैं:

1) Win32 अपवाद क्यों नहीं पकड़े जाते हैं।

2) क्या यह उच्चतम स्तर पर अपवादों को पकड़ने का एक अच्छा अभ्यास है।

Answer 1

EDIT: Pratik के अनुसार, निम्न उत्तर .NET 1.0 और .NET 1.1 पर लागू होता है। .NET 2.0 से शुरू होने पर, गैर-सीएलएस अपवाद को RuntimeWrappedException के रूप में पकड़ा जाना चाहिए।

---

क्योंकि Win32 अपवाद .NET अपवाद वर्ग से प्राप्त नहीं होते हैं। आज़माएं:

try { 
} catch (Exception ex) { 
    // .NET exception 
} catch { 
    // native exception 
} 

अधिक जानकारी के लिए Catch non-CLSCompliant exceptions in general handlers देखें।

Answer 2

आप Win32Exception (या ExternalException) के रूप में पकड़ने के लिए आवश्यकता हो सकती है बजाय

http://msdn.microsoft.com/en-us/library/system.componentmodel.win32exception.aspx

मुझे याद है कि Win32Exception ExternalException लेकिन ExternalException से विरासत तो अपवाद से विरासत नहीं है कि आपके कोड से पकड़ा नहीं जाएगा लगते हैं ।

संपादित करें: यह गलत क्यों है इसके अन्य उत्तरों देखें!

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

Answer 3

एप्लिकेशन का निष्पादन। रून एक त्रुटि फेंक नहीं रहा है। यह एक और थ्रेड (या कम से कम असीमित रूप से) पर हो रहा है।

उपयोगकर्ता को यह सूचित करने का अच्छा विचार है कि एप्लिकेशन पूरी तरह से अपमानित होने से पहले विफल रहा है, हालांकि इसे पकड़ने के लिए एक अच्छा विचार नहीं है।

Answer 4

जबकि मुझे नहीं पता कि आपका कैच ब्लॉक काम क्यों नहीं करता है Application ThreadException Event का उपयोग करने का प्रयास करें। इसे एप्लिकेशन थ्रेड में कोई त्रुटि पकड़नी चाहिए। एप्लिकेशन कॉल करने से पहले एक ईवेंट हैंडलर जोड़ें। रुन।

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

Answer 5

1) Win32 अपवादों को पकड़ा जाना चाहिए। शायद अपवाद को पृष्ठभूमि धागे या जीसी थ्रेड से फेंक दिया जा रहा है?

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

Answer 6

आपके आवेदन शुरू होता है (Application.Run) से पहले इन घटनाओं की सदस्यता का प्रयास करें:

• AppDomain.CurrentDomain.UnhandledException।
• Application.ThreadException।

तब आप अपने try catch ब्लॉक से छुटकारा पा सकते हैं।

---

मुझे लगता है कि उच्चतम स्तर पर अपवादों को पकड़ने के लिए यह बुरा अभ्यास है, लेकिन आप इससे बच नहीं सकते! विकास (डीबग) के दौरान, उन अपवादों को पकड़ा नहीं जाना चाहिए और आवेदन को सबसे नस्लीय चीज़ संभव (क्रैश?) करना चाहिए। उत्पादन (रिलीज) में, आप चाहते हैं कि आपके एप्लिकेशन को यथासंभव अच्छी तरह से अपनाना पड़े, भले ही अनचाहे अपवाद हों। यह DEBUG preprocessor variable के लिए मिले कुछ उपयोगों में से एक है।