.NET Framework अपवाद हैंडलिंग को अक्षम कैसे करें और इसके बजाय अपना स्वयं का उपयोग करें?

Question

मैंने एक .NET 4 सॉफ्टवेयर विकसित किया है और मैं इसे बीटा उपयोगकर्ताओं को भेजने के लिए तैयार हूं। यदि सॉफ़्टवेयर में एक अनचाहे अपवाद फेंक दिया गया है, तो मैं इसे पकड़ना, लॉग इन करना और लॉग भेजना चाहता हूं। मैंने पहले से ही इस कार्यक्षमता को कार्यान्वित कर दिया है और जब मैं इसे विजुअल स्टूडियो के साथ डीबग मोड में चलाता हूं तो यह ठीक चल रहा है। हालांकि, जब मैंने सॉफ़्टवेयर का रिलीज़ संस्करण बनाया है और इसे इंस्टॉल किया है, तो माइक्रोसॉफ्ट .NET Framework मेरे कोड से पहले अपवाद पकड़ना शुरू कर देता है। मुझे एक त्रुटि संदेश वाला पॉपअप मिलता है: "आपके एप्लिकेशन में किसी घटक में अनचाहे अपवाद हुआ है। यदि आप जारी रखें क्लिक करते हैं, तो एप्लिकेशन इस त्रुटि को अनदेखा कर देगा और जारी रखने का प्रयास करेगा।"

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

AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException; 

वहाँ .NET फ्रेमवर्क के पकड़ने अपवाद निष्क्रिय करने के लिए कोई रास्ता है या अपने ही अपवाद संचालक संलग्न करने के लिए एक बेहतर तरीका है:

मैं इस कोड के साथ अपने ही अपवाद संचालक संलग्न किया है?

अद्यतन: मैं WPF का उपयोग कर रहा हूं। मैं DispatcherUnhandledException में देखूंगा और आपको यह बता दूंगा कि क्या यह समस्या हल करता है।

अद्यतन # 2: दुर्भाग्य से आवेदन करने के लिए हैंडलर जोड़ना। वर्तमान। डिस्पैटर अननहेल्ड अपवाद ने समस्या का समाधान नहीं किया। स्पष्ट रूप से यह डीबगिंग पॉपअप जेआईटी (जस्ट-इन-टाइम) डीबगर द्वारा बनाया गया है जो विजुअल स्टूडियो के साथ शामिल है। मुझे सॉफ़्टवेयर का परीक्षण "नागरिक" विंडोज के साथ करना होगा और देखें कि अपवाद भी वहां पहुंचे हैं या नहीं।

अद्यतन # 3: किसी कारण दृश्य स्टूडियो काम करता है लेकिन रिलीज MSBuild स्क्रिप्ट और Dotfuscator के साथ बनाया के साथ बनाया गया जारी नहीं करता है के लिए।

Answer 1

मैंने अंततः समस्या हल की। समस्या गलत अपवादों को सुनकर नहीं हुई थी, लेकिन जारी संस्करण से डीएलएल गायब होने के कारण।

प्रेषित UnnhandledException और थ्रेड अपवाद घटनाओं के श्रोताओं को जोड़ने के बाद मुझे अब अजीब माइक्रोसॉफ्ट .NET Framework पॉपअप नहीं मिला है जो उपयोगकर्ता को अपवाद के बाद सॉफ़्टवेयर चलाने जारी रखने की अनुमति देता है। हालांकि इस बिंदु पर मेरा अपवाद हैंडलिंग अभी भी टूट गया था।

क्योंकि इस समय सॉफ़्टवेयर पहले से ही क्रैश हो रहा था जब अपवाद हैंडलर को लात मारना था, मेरे पास अपवाद हैंडलर के आसपास एक पकड़ (अपवाद) था। इस पकड़ को हटाने के बाद मुझे अंततः रिलीज संस्करण के साथ सही त्रुटि संदेश मिला और गायब डीएलएल जोड़े।

मैंने जो सबक सीखा (दोबारा) है: खाली पकड़ (अपवाद) ब्लॉक का उपयोग न करें। यह बुरा है।

Answer 2

Main() में try ... catch ब्लॉक होगा?

Answer 3

आपने निर्दिष्ट नहीं किया है कि आप किस फ्रेमवर्क का उपयोग कर रहे हैं, लेकिन अन्य "अनचाहे अपवाद" घटनाएं हैं।

विंडोज फॉर्म के लिए, Application.ThreadException है।

WPF/Silverlight के लिए Application.DispatcherUnhandledException है।

उन दो में से किसी एक को आजमाएं, और हमें बताएं कि क्या आपको अभी भी समस्याएं हैं।

Answer 4

ऐसा लगता है जैसे अपवाद आपके एप्लिकेशन के संदेश पाश पर बुलबुला कर रहा है। विंडोज फॉर्म में, आप Application.ThreadException ईवेंट के लिए इवेंट हैंडलर सेट करके इन्हें संभाल सकते हैं। डब्ल्यूपीएफ/सिल्वरलाइट में, समकक्ष घटना Application.DispatcherUnhandledException होगी।

आप अच्छी माप के लिए अपनी मुख्य विधि (यदि आपके पास हैं) में भी कोशिश/पकड़ डाल सकते हैं लेकिन यूआई आमतौर पर अपवादों को पकड़ लेगा जैसा आपने देखा है।

संपादित

WPF/Silverlight में, सेट e.Handled = ढेर अप जारी रखने से अपवाद को रोकने के लिए सही।

Answer 5

आप AppDomain class and the UnhandledException ईवेंट और Application.ThreadException event पर देख सकते हैं। इन्हें अनचाहे अपवादों को पकड़ लिया जाएगा, क्योंकि अपवादों के लिए आप अपने आप को एक प्रयास-पकड़ ब्लॉक के साथ संभालने वाले हैं, आप अपने अपवादों को प्रबंधित करने के लिए एक सहायक वर्ग लिख सकते हैं और जो भी आपको उनके साथ चाहिए। आप संभाले गए अपवादों के लिए उस कक्षा में तीसरी घटना भी लिख सकते हैं।

Answer 6

UnhandledException घटना के प्रलेखन से,

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

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

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

Answer 7

ओच ... डॉटफुस्केटर आपको एक अमान्य असेंबली उत्पन्न करता है जो कि JIT'able नहीं है। जेआईटी अपवादों को उपयोगकर्ता कोड द्वारा कभी पकड़ा नहीं जा सकता है। यह StackOverflowException को पकड़ने के तरीके के समान नहीं है क्योंकि रनटाइम आपको गारंटी नहीं दे सकता है कि यह सुरक्षित त्रुटि स्थिति से सुरक्षित रूप से पुनर्प्राप्त हो सकता है।

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

वैसे भी, दो बातें आप देख सकते हैं:

1. भागो PEVerify अपने टूट/काम कर विधानसभा पर और उत्पादन की तुलना करें।
2. यह देखने के लिए कि क्या आप त्रुटि को उत्तेजित कर सकते हैं, अपनी टूटी हुई असेंबली पर एनजीएनएन आज़माएं।

Answer 8

// Add the event handler for handling UI thread exceptions to Windows Form Events. 
    // Uses SystemThreading. 
    // NOTE: Remember to turn Execption Handler OFF in the Debugger for testing!! Debug -> Common Language Runtime Exceptions -> User-Unhandled -> OFF. 
    // NOTE: A separate Event Handler is Needed for other threads added to the Application. 
    // NOTE: Methods can catch, inform, then throw for logging and emailing as well. 
    // Add these to Program.cs. 
    static void Main() 
    { 
      Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException); 

      // Set the unhandled exception mode to force all Windows Forms errors to go through the Handler. 
      Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException); 

      // ... 
    } 

    // Then put your handler in the method referenced in the event definition above. 
    static void Application_ThreadException(object sender, ThreadExceptionEventArgs e) 
    { 
     // Your Code ... 
    } 

    // Sorry for the ragged listing. Still getting used to the editor here.