विजुअल स्टूडियो 2015 काम न करने वाले अपवादों को तोड़ता है

Question

विज़ुअल स्टूडियो के पास "अन-हैंडल किए गए अपवाद पर ब्रेक" के लिए एक विशिष्ट चेकबॉक्स होता था। 2015 में यह हटा दिया गया है (या मुझे कहीं नहीं मिला)। इसलिए अब मेरी परिवर्तित परियोजनाएँ नहीं टूटतीं अगर मैं एक उपयोगकर्ता-स्तरीय अपवाद हैंडलर प्रदान करने में विफल रहता हूँ। मैं सभी "फेंके गए अपवादों" को नहीं तोड़ना चाहता क्योंकि मैं विशिष्ट लोगों को संभालता हूं। बस जहां मैं एक विशिष्ट हैंडलर प्रदान करने में विफल रहता हूं।

अभी मेरा कोड केवल वर्तमान प्रक्रिया से बाहर निकलता है और अगले कॉल स्टैक स्थान, नॉट गुड पर निष्पादन जारी रखता है।

किसी को पता है कि यह कैसे Visual Studio 2015 में वापस पाने के लिए? मैं कल ही सामुदायिक संस्करण में उन्नत हुआ।

Comments

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

— ग्रेग

@ समूह, ऐसा नहीं है कि मुझे नहीं पता कि पैनल कहां मिलेगा। मेरी चिंता यह है कि जिस व्यवहार की मुझे तलाश है, वह उस पैनल में नहीं है।

— टेड लोरी जुले

यहां भी यही समस्या। हमारे मामले में हमें उम्मीद है कि जब ऑटोफाक में सभी प्रकार के पंजीकरण नहीं होंगे, तो एक अपवाद विराम होगा। Vs2013 के साथ एक ही समाधान का उपयोग करना, बनाम2015 में हमें कुछ भी नहीं मिलता है। यह अन्य तीसरे पक्ष के पंजीकरण और अपवादों (जैसे nservicebus) के साथ भी एक समस्या है। मुझे आश्चर्य है कि अगर यह केवल vs2013 में बनाई गई परियोजना के लिए मामला है और vs2015 में भाग गया

— चोको स्मिथ

वह नया टूल विंडो वास्तव में बेकार है।

— cedd

के अनुसार अपवाद के एमएस वर्गीकरण अगर आपके पास बिना क्रिया अपवाद यह हमेशा डिबगर टूट जाता है। हो सकता है कि आपको "विकल्प -> डिबगिंग -> सामान्य सूची" सूची में "AppDomain ..." के पार जाने पर विकल्प को चेक करना होगा।

— tsul

Answer 1

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

आप इसे के साथ ला सकते हैं CTRL+ ALT+E

यह आपको चेरी-पिक करने की अनुमति देता है जो अपवाद डीबगर में एक ब्रेक का कारण बनता है।

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

आपको उपकरण> विकल्प> डिबगिंग के तहत पहले "सक्षम जस्ट माई कोड" की जांच करनी होगी।

यह आपको नई अपवाद सेटिंग विंडो में कॉलम हेडर (ब्रेक व्हेन थ्रोएन) पर राइट-क्लिक करने की अनुमति देता है, और "अतिरिक्त क्रियाएं" कॉलम जोड़ें, जो तब आपको प्रत्येक अपवाद को "जारी रखें जब उपयोगकर्ता कोड में अखंडित" के रूप में सेट करने की अनुमति देता है।

इसलिए केवल एक अपवाद या संपूर्ण समूह पर राइट-क्लिक करें और "जारी रखें जब उपयोगकर्ता कोड में अखंडित करें" ध्वज को अक्षम करें। दुर्भाग्य से, "अतिरिक्त क्रियाएँ" कॉलम खाली दिखाई देगा जो कि "उपयोगकर्ता कोड में अनहेल्ड होने पर ब्रेक" के समान है।

इस पर यहाँ और अधिक:

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

Comments

वास्तव में उस विंडो में केवल "थ्रो के साथ विराम" के विकल्प हैं। वह नहीं है जो मैं चाहता हूं। मैं "जब खंडित हो तो" चाहता हूं।

— टेड लोरी जुएल

और यही समस्या है। यह टूटता नहीं है। जैसा कि मैंने ऊपर कहा, यह मौजूदा प्रक्रिया कॉल से बाहर निकलता है (कॉल आउट) और कॉलिंग प्रक्रिया में कोड की अगली पंक्ति को निष्पादित करना शुरू करता है।

— टेड लोवी जुएल

और मेरे पास "जस्ट माई कोड" सक्षम है।

— टेड लोरी जुएल

@TomStudee मेरी भी यही समस्या है। मैं जो चाहता हूं वह है "जब खंडित हो तो तोड़ो" लेकिन मुझे जो मिलता है वह है "जब फेंका जाता है तो तोड़ देना"। सवाल यह है: "जब अनहेल्ड हो तो ब्रेक" कैसे प्राप्त करें?

— ऑगग्रे

@TomStudee मैंने केवल कुछ बहुत जरूरी स्पष्टीकरण जोड़े हैं, क्योंकि आप महत्वपूर्ण सेटिंग को याद नहीं कर रहे थे जो आपको केवल खंडित होने पर अपवादों को सेट करने की अनुमति देता है।

— जेरड रोज़

Answer 2

मेरे पास एक ही मुद्दा था और मैं यह करके इसे हल करने में कामयाब रहा -

1. अपवाद सेटिंग विंडो को लाने के लिए Ctrl+ Alt+ दबाएँ ।e
2. टिक आम भाषा रनटाइम अपवाद ।

बस!

मैं इस पोस्ट से प्रेरित था क्योंकि मैं विंडोज के x64 संस्करण का उपयोग कर रहा हूं ।

Comments

यह सभी अपवादों पर टूटने का कारण होगा, यहां तक ​​कि उपयोगकर्ता कोड द्वारा नियंत्रित भी।

— carlin.scott

@ carlin.scott, मेरा मानना ​​है कि आप सूची से हाथ लगे अपवादों को मैन्युअल रूप से अनचेक कर सकते हैं।

— जस्टिन एक्स्ट्रा लार्ज

@JustinXL यह समस्या है, यह अपवाद प्रकार द्वारा एक सूची है, न कि इसके द्वारा नियंत्रित किया जाता है या नहीं। उदाहरण के लिए, ऐसे समय होते हैं जब System.ArgumentExceptionसंभाला जाता है, और कई बार ऐसा नहीं होता है। मैं केवल तब टूटने की परवाह करता हूं जब इसे संभाला नहीं जाता।

— जेरेड रोज

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

— जस्टिन एक्सएल

यहां तक ​​कि सब कुछ की जाँच करते समय यह एक अपवाद पर नहीं टूट रहा है: / बस बाहर निकलना

— डगलस गास्केल

Answer 3

गोगलर के लिए जो केवल तभी टूटना चाहता है जब अपवाद उनके कोड की चिंता करता है, विजुअल स्टूडियो 2015 में एक विकल्प होता है: विकल्प-> डिबगिंग-> जनरल-> जस्ट माय कोड। एक बार जांच करने के बाद, यह अपवाद को प्रबंधित करने (फेंकने और पकड़ने) के दौरान टूटने की अनुमति नहीं देता है।

Comments

इसने मुझे एक और स्थिति के लिए बचा लिया, जहां किसी कारण से VS2015 ने कुछ कोड दर्ज करने से इनकार कर दिया। कोड "मेरा" है, लेकिन कुछ ने "बस मेरा कोड" ध्वज को ट्रिगर किया। मुझे लगता है कि वीएस के 2 उदाहरण और एक स्टैंड अकेले वेब सर्वर चलाने पर एक बग कहीं है और शायद कुछ और।

— लॉसमनोस

Answer 4

Microsoft ने नए अपवाद विंडो में तर्क को आसानी से बदल दिया है।

Http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx देखें

प्रमुख हिस्सा है:

महत्वपूर्ण लेख

• इस नई विंडो में पुराने मोडल डायलॉग की तरह ही कार्यक्षमता है। डीबगर की किसी भी क्षमता ने केवल उस तरीके को नहीं बदला है जिससे आप उन्हें एक्सेस कर सकते हैं
• डिबगर हमेशा एक अपवाद नहीं होने पर टूट जाएगा
• यदि डिबगर उपयोगकर्ता-अनहैंड किए गए अपवादों पर तोड़ता है तो संदर्भ मेनू के तहत स्थानांतरित होने पर बदलने की सेटिंग
• मेनू स्थान डिबग -> विंडोज -> अपवाद सेटिंग्स में स्थानांतरित हो गया है

हालाँकि , यदि आप की तरह मेरे पास भी आपके कोड में एक ग्लोबल अनहैंडल्ड एक्सेप्शन हैंडलर है , तो उस सूची में दूसरा आइटम मुख्य है: मेरे लिए, कोई अपवाद इसलिए वास्तव में अनहेल्ड नहीं होगा, जो VS2013 से अलग प्रतीत होता है।

व्यवहार को वापस पाने के लिए जहां वीएस अखंडित अपवादों पर टूट जाता है, मुझे उन सभी अपवाद प्रकारों पर टिक करना था जिन्हें मैं तोड़ना चाहता था और फिर दूसरी बात यह सुनिश्चित करता हूं कि "जारी रखें" के लिए "अतिरिक्त विकल्प" (आपको यह कॉलम दिखाई देने की आवश्यकता हो सकती है) * जारी रखें जब उपयोगकर्ता कोड में unhandled " सेट नहीं किया गया था । VS2015 लॉजिक मेरे ग्लोबल अनहैंड एक्सेप्शन हैंडलर को "उपयोगकर्ता कोड में संभाला" नहीं लगता है , इसलिए यह इन पर टूट पड़ता है; हालांकि यह पकड़े गए अपवादों पर नहीं टूटता है। यह इसे VS2013 की तरह काम करता है।

* "अतिरिक्त क्रियाएँ" कॉलम को कैसे सक्षम करें

Comments

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

— carlin.scott

आप "अतिरिक्त विकल्प" कॉलम को कैसे देखते हैं?

— UuDdLrLrSs

@DaveInCaz कॉलम शीर्षक पर राइट-क्लिक करें> "कॉलम दिखाएं"> "अतिरिक्त कार्य"

— ओट्सोडा

Answer 5

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

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

उदाहरण के लिए, इस कोड को देखें:

class Program
{
    static void Main(string[] args)
    {
        Test();
        Console.ReadLine();
    }

    private async static Task Test()
    {
        await Task.Delay(100);
        throw new Exception("Exception!");
    }
}

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

ध्यान दें, इस मामले में, वास्तविक मुद्दा यह है कि इसके Taskद्वारा लौटाया गया Test()चेक कभी नहीं किया जाता है। यदि आपके पास अपने कोड में समान प्रकार के 'फायर-एंड-भूल' तर्क है, तो आप उस समय के अपवादों को नहीं देखेंगे जो उन्हें फेंक दिए गए हैं (भले ही वे विधि के अंदर 'अखंडित' हों); अपवाद केवल तब दिखाई देता है जब आप कार्य का इंतजार करके उसका निरीक्षण करते हैं, उसके परिणाम की जांच करते हैं या स्पष्ट रूप से उसके अपवाद को देखते हैं।

यह सिर्फ एक अनुमान है, लेकिन मुझे लगता है कि यह संभावना है कि आप इस तरह से कुछ देख रहे हैं।

Comments

हालांकि यह ऑप्स के मुद्दे से संबंधित नहीं हो सकता है, यह async दिनचर्या में उठाए गए अपवादों के बारे में बहुत अच्छा बिंदु उठाता है।

— फिल कूपर

क्या डिबगर को बंद करने का एक तरीका है, भले ही अपवाद उस तरह संग्रहीत हो?

— लुकास

@ लुकास, ऐसा नहीं है कि मुझे पता है, हालांकि आप कुछ कोड परिवर्तनों के साथ पास हो सकते हैं। यदि आपके फायर-एंड-फॉरगेट मेथड बॉडी में ट्राइ-कैच ब्लॉक है, तो आप एक स्पष्ट Debugger.Break()कॉल जोड़ सकते हैं । वैकल्पिक रूप से, आप हैंडलर Debugger.Break()में एक स्पष्ट जोड़ सकते हैं TaskScheduler.UnobservedTaskException, हालांकि यहां नकारात्मक पक्ष यह है कि यह मूल अपवाद की तुलना में बहुत बाद में आग लगा सकता है, क्योंकि यह फाइनल थ्रेड पर तब होता है जब टास्क साफ हो जाता है। सामान्य तौर पर आपको टास्क के परिणामों का हमेशा निरीक्षण करने का प्रयास करना चाहिए या असफलता के समय लॉग करने के लिए कम से कम कोशिश करने वाला ब्लॉक होना चाहिए।

— दान ब्रायंट

Answer 6

यदि आप कुछ भी बदलते हैं तो मेरे अनुभव में 2015 में अपवाद सेटिंग्स पूरी तरह से बेकार से बाहर हो गईं।

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

समाधान: नए अपवाद सेटिंग्स टूलबॉक्स में, राइट-क्लिक करें और "रिस्टोर डिफ़ॉल्ट" चुनें। टाडाआ ... यह सामान्य रूप से फिर से व्यवहार करता है। अब इसके साथ पेंच मत करो।

Answer 7

निर्देशों का पालन करने का प्रयास करें:

1. अपवाद सेटिंग विंडो में, विंडो में राइट-क्लिक करके संदर्भ मेनू खोलें और फिर शो कॉलम का चयन करें। (यदि आपने जस्ट माई कोड को बंद कर दिया है, तो आप यह कमांड नहीं देखेंगे।)
2. आपको अतिरिक्त क्रियाएँ नाम का एक दूसरा कॉलम देखना चाहिए। विशिष्ट अपवादों पर उपयोगकर्ता कोड द्वारा अनहेल्ड किए जाने पर यह कॉलम प्रदर्शित होता है, जिसका अर्थ है कि डिबगर नहीं टूटता है यदि वह अपवाद उपयोगकर्ता कोड में संभाला नहीं जाता है लेकिन बाहरी कोड में संभाला जाता है।
3. आप इस सेटिंग को या तो एक विशेष अपवाद के लिए बदल सकते हैं (अपवाद का चयन करें, राइट-क्लिक करें, और उपयोगकर्ता कोड में अनहैंड किए जाने पर जारी रखें / चयन रद्द करें) या अपवादों की पूरी श्रेणी के लिए (उदाहरण के लिए, सभी सामान्य भाषा रनटाइम अपवाद)।

https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx

Comments

बिलकुल सहमत। यह कॉलम डिफ़ॉल्ट रूप से नहीं दिखाना भयानक है। इसे खोजने के लिए बहुत समय बिताया। बशर्ते, " उपयोगकर्ता बिना किसी अपवाद के " का अर्थ स्पष्ट नहीं है। मेरे पास टास्क कैंसिलेशन (जैसे कुछ भी try { task.Wait(); } catch { ... }) का मेरा हैंडलर था और कार्य में OperationCanceledException को उपयोगकर्ता कोड में किसी भी तरह अनहेल्ड माना जाता था।

— tsul

Answer 8

यह सब थोड़ा भ्रामक है, और मेरी राय में पुराने अपवादों के संवाद के रूप में अच्छा नहीं है, लेकिन वैसे भी।

यदि कोई अपवाद सूची में है और टिकटिक है तो डिबगर तब भी टूट जाएगा जब अपवाद को फेंक दिया जाएगा।

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

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

Answer 9

जब मैंने VS2015 में अपग्रेड किया, तो मेरे पास ऐसे मुद्दे भी थे, जहां अपवाद एप्लिकेशन को "ब्रेक" करने के लिए उपयोग किया जाता था, लेकिन अब इसे अनदेखा कर दिया गया और सही तरीके से पारित कर दिया गया। ऐसे समय होते हैं जब हम चाहते हैं कि हमारा कोड जानबूझकर अपवादों को उन स्थानों पर फेंक दे जहां हम चाहते हैं कि कोड जारी न रहे। Throw New Exception("Message")अपने कोड को जानबूझकर तोड़ने के लिए हम हमेशा वाक्यांश का उपयोग करते हैं :

    If SomethingReallyBad = True Then
        Throw New Exception("Something Really Bad happened and we cannot continue.")
    End If

VS2015 के साथ, क्लासिक "System.Exception" वह है जिसे हम कहते हैं Throw New Exception। इसलिए, हमें नई अपवाद सेटिंग में "System.Exception" टिक की जांच करने की आवश्यकता है:

System.Exception बॉक्स की जाँच करें

एक बार जाँच करने के बाद, हमारे कोड ने उम्मीद के मुताबिक काम किया।

Answer 10

इसका समाधान यह है कि आप जो सोच रहे हैं उसके विपरीत शब्दार्थ है। आपको यह सुनिश्चित करने की आवश्यकता है कि जब उपयोगकर्ता कोड में अनहेल्ड सक्षम नहीं है तो जारी रखें अर्थात अपवाद सेटिंग्स टैब में अतिरिक्त क्रिया कॉलम के तहत दिखाया नहीं गया है - नीचे देखें:

आप प्रभावी रूप से कह रहे हैं कि कोड में अखंडित होने पर (यानी ब्रेक) जारी न रखें

यह करने के लिए:

1. उस अपवाद या सेट के अधिकार पर क्लिक करें , जिसकी आप परवाह करते हैं (यानी आमतौर पर पेड़ में 'सामान्य भाषा रनटाइम एक्सेप्शन')
2. विकल्प का चयन करें जारी रखें जब उपयोगकर्ता कोड में अनहैंड किया गया हो (नीचे देखें)
3. सुनिश्चित करें कि अपवादों की जाँच नहीं की गई है (नीचे देखें)
4. डिबगिंग जारी रखें

यह मेरे लिए किया - फिर से खुश।

यह वीएस 2015 में था

Answer 11

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

मेरे पास एक एकल पिरोया स्थिति थी जहां एक NullReferenceException'बाहरी' हैंडलर (अभी भी मेरे कोड में) द्वारा पकड़ा जा रहा था, भले ही मैंने इसे उठाने के लिए कहा।

मुझे एहसास है कि यह एक 'संभाला' अपवाद है और आप एक 'अनहेल्ड' की बात कर रहे हैं - हालांकि मुझे पूरा यकीन है कि कभी-कभी वीएस का एक त्वरित पुनरारंभ इसे ठीक कर देगा, अगर IISRESET नहीं करता है।

Answer 12

Visual Studio 2017 त्रुटि से निपटने के साथ ठीक काम करता है। दूसरी ओर विजुअल स्टूडियो 2015 कार्यों के साथ त्रुटि से निपटने में बेकार हो जाता है क्योंकि डिबग मोड में एक एसिंक्स कार्य में होने वाले सभी अपवाद पकड़े जाते हैं लेकिन फिर अगर मैं इस पर कदम रखता हूं तो बस अनिश्चित काल तक लटका रहता है। यदि डिबगिंग के बिना निष्पादित किया जाता है तो यह बिना किसी अपवाद के अनिश्चित काल तक लटका रहता है !!! मुझे दृश्य स्टूडियो बहुत पसंद है और 1995 से 2015 तक इसका उपयोग किया जा रहा है, लेकिन अब तक इसका सबसे खराब संस्करण है, हालांकि मैं 2010 से 2015 तक सीधे कूद गया था। मैंने इस अपवाद को बिना किसी सफलता के साथ काम करते हुए पाने में 8 घंटे बिताए। मैंने अपने होम कंप्यूटर पर 2017 के सटीक कोड की प्रतिलिपि बनाई और यह पूरी तरह से काम करता है। मुझे बहुत चिढ़ है कि Microsoft ने ऐसे कार्यों को एक ढाँचे में ढकेल दिया जिसे 2015 संकलक सही ढंग से नहीं संभाल सकता।