प्रक्रिया को संलग्न करने पर System.Diagnostics.Debugger.Break() का उपयोग करने के क्या फायदे हैं?

Question

विजुअल   स्टूडियो   2008 का उपयोग करके, मेरे मनोदशा के आधार पर डीबगिंग शुरू करने के लिए, मैं या तो प्रक्रिया में संलग्न होगा और इस तरह ब्रेकपॉइंट्स को हिट करूंगा या मैं कोड में प्रासंगिक स्थान पर System.Diagnostics.Debugger.Break() रखूंगा और उस पर टूटने पर डीबगिंग शुरू करूंगा बिंदु।

उत्तरार्द्ध आवश्यक कभी-कभी मुझे लगता है!

नहीं बात कर के बारे में F5 -> एक पल के लिए डिबग मोड में चल रहा है ...

System.Diagnostics.Debugger.Break(); 

सवाल:

क्यू) मैं के बीच मामूली अंतर के रूप में उत्सुक हूँ प्रत्येक विकल्प?

क्यू) प्रत्येक का उपयोग करने के लाभ और कमी क्या हैं?

मैं इसे शुरू होगा ...

Debugger.Break() दोष = Debugger.Break के बारे में भूल जाते हैं() के लिए और उन्हें वहाँ में छोड़ रहा है!

डीबगर। ब्रेक() लाभ = अन्य अनावश्यक ब्रेकपॉइंट्स को मारने के बिना जहां आप चाहते हैं वहां डिबगिंग शुरू करें जो अभी भी कोड में हो सकता है जो प्रक्रिया से जुड़ा हुआ होगा।

पहले कार्रवाई नापसंद करने

मैं सिर्फ नापसंद करने कि निस्संदेह अगर मैं Debugger.Break() मैं डिबगिंग का सही तरीका समझ नहीं कर रहा हूँ उपयोग कर रहा हूँ कहेंगे पहले कार्रवाई की जाती है।

मैं बस यहां एक वार्तालाप शुरू करने की कोशिश कर रहा हूं क्योंकि मुझे लगता है कि परिस्थितियों के आधार पर डीबगिंग के विभिन्न तरीके हैं।

Answer 1

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

एक और उदाहरण; मैं पावरशेल के लिए एक cmdlet लिख रहा था। वे जिन्हें आप विजुअल स्टूडियो में नहीं चलाते हैं; आप उन्हें PowerShell कमांड लाइन से चलाते हैं। वे आमतौर पर त्वरित छोटे अनुप्रयोग होते हैं, और प्रक्रिया के साथ पर संलग्न होने का कोई तरीका नहीं है।

Answer 2

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

if(System.Diagnostics.Debugger.IsAttached) 
{ 
    System.Diagnostics.Debugger.Break(); 
} 

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

हाँ, मुझे पता है कि यह विशेष रूप से अच्छा अभ्यास नहीं है और मैं इसे नए कोड में कभी नहीं करूंगा। लेकिन मेरा विश्वास करो, अगर आप उस कोड बेस के माध्यम से spelunking थे, तो आप कुछ ऐसा ही किया होगा। ;)