2009-12-03 16 views
5

मैं एक अजीब छोटी समस्या में भाग गया है।कैप्चर अपवाद कैसे शून्य हो सकता है (NullReferenceException नहीं)?

निम्नलिखित कोड में मैं समझ नहीं सकता कि enull हो सकता है;

try 
{ 
    //Some Code here 
} 
catch (Exception e) 
{ 
    //Here e is null 
} 

जहाँ तक मुझे पता है, throw nullthrow new NullReferenceException() में परिवर्तित हो जाएगा।

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

वैसे भी मेरा सवाल है, e कैसे शून्य हो सकता है? - उम्मीद है कि इसका उत्तर इस समस्या के स्रोत को खोजने में मदद कर सकता है।

संपादित मैं यह खोज की है, क्योंकि यह पकड़ बयान में एक NullReferenceException का कारण बना, और डीबगर मैं एक ही बात को देखने का उपयोग कर।

संपादित 2 ओपन VisualStudio अगले दिन फिर से करने की कोशिश की, कोई कोड परिवर्तन और अब एक ही पकड़ वाक्यांश "कहा जाता है" है लेकिन इस बार ई अशक्त नहीं है। ऐसा लगता है कि यह एक वीएस गड़बड़ था।

+0

ऐसा लगता है जैसे आप पहले से ही अपनी उंगली को समस्या पर डाल देते हैं। आपको सीधे चलने की जरूरत है। –

उत्तर

7

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

क्या आप इस मान को सत्यापित करने के लिए डीबगर का उपयोग कर रहे हैं? यदि ऐसा है, तो इसे एक इनलाइन जोर से स्विच करने का प्रयास करें।

+0

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

+3

@ लिलेमंडन, यह साबित नहीं करता है कि यह शून्य है। केवल एक डीबग। एस्र्टर्ट (ई! = नल, "यह निश्चित रूप से शून्य है") या एक समान चेक यह करेगा। – JaredPar

+2

डीबगर कभी-कभी झूठ बोलता है। मुझे याद है कि स्थिरता के साथ कुछ मनोरंजक है और डीबगर जहां वे वास्तविकता में नहीं हैं, वे खाली या शून्य लगते हैं। – Quibblesome

1

यह संभव है कि फेंक दिया जा रहा अपवाद सीएलएस अनुपालन नहीं है, जो वास्तव में फ़िल्टर के साथ प्रयास/पकड़ द्वारा पकड़ने योग्य नहीं होना चाहिए।

आप केवल कोई अपवाद नहीं "कथन" के साथ एक कोशिश {} {} पकड़ के साथ एक सीएलएस अनुरूप पकड़ने के लिए सक्षम होना चाहिए

+0

मुझे पूरा यकीन है कि सभी कोड सीएलएस अनुपालन है। हालांकि 100% नहीं। लेकिन मुझे पहले कभी यह समस्या नहीं आई है। और ऐसे कई अन्य कैच स्टेटमेंट हैं, जिनमें से अधिकांश को यूनिट परीक्षणों द्वारा परीक्षण किया जाना चाहिए था। –

2

आप कर रहे हैं सकारात्मक आप अपवाद ई लाइन बंद कर रहे थे?

try 
{ 
    //Some Code here 
} 
catch (Exception e) 
{ 
    int i = 0; // breakpoint here 
} 

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

+0

हां, मैं सकारात्मक हूं। कैच स्टेटमेंट के अंदर ई का उपयोग करने से वहां एक NullReferenceException हुआ। –

0

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

संबंधित मुद्दे