debugging आईडीई में बेहतर डिबगिंग क्यों है?




ide (24)

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

उस ने कहा, आपको वास्तव में पता होना चाहिए कि चरण-दर-चरण डीबगर का उपयोग कैसे करें, क्योंकि बग की एक अलग श्रेणी के लिए यह आसान तरीका है। मैं इसे पहले से पोस्ट किए गए अन्य उत्कृष्ट उत्तरों तक छोड़ दूंगा ताकि क्यों समझाया जा सके :)

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

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

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

मैं क्या खो रहा हूँ? क्या डायग्नोस्टिक print स्टेटमेंट के विचारशील उपयोग से आईडीई डीबगिंग टूल इतना अधिक प्रभावी बनाता है?

क्या आप संसाधनों (ट्यूटोरियल, किताबें, स्क्रीनकास्ट) का सुझाव दे सकते हैं जो आईडीई डीबगिंग की बेहतर तकनीक दिखाते हैं?

मीठे जवाब! समय लेने के लिए हर किसी के लिए बहुत बहुत धन्यवाद। बहुत रोशनी मैंने कई लोगों को वोट दिया, और किसी को भी वोट नहीं दिया।

कुछ उल्लेखनीय अंक:

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

आईडीई डीबगर के साथ आप निष्पादन को रोकते समय मौजूदा दायरे में सभी चर के मूल्य (कॉल स्टैक तक सभी तरह से) देख सकते हैं।

प्रिंट स्टेटमेंट बहुत अच्छा हो सकता है लेकिन किसी भी स्थान पर स्क्रीन पर इतनी सारी जानकारी डंपिंग पूरे प्रिंट स्टेटमेंट का उत्पादन कर सकती है।

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

मुझे लगता है कि कुछ भाषाओं के लिए डिबगर्स दूसरों के मुकाबले बेहतर हैं ...

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

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


जैसा कि ऊपर बताया गया है: डीबगर! = आईडीई।

जीडीबी और (दिन में वापस) टर्बोडेबगर (स्टैंड-अलोन) उन भाषाओं के लिए ठीक काम करता है जो वे समर्थन करते हैं [ed], धन्यवाद। (या यहां तक ​​कि पुरानी तकनीक: क्लिपर डीबगर xBase निष्पादन योग्य में स्वयं जुड़ा हुआ है) - इनमें से कोई भी आईडीई की आवश्यकता नहीं है

इसके अलावा, हालांकि सी / ++ कोडिंग अधिक दुर्लभ है, प्रिंटफ स्टेटमेंट कभी-कभी उस बग को मुखौटा करते हैं जिसे आप ढूंढने की कोशिश कर रहे हैं! (स्टैक पर ऑटो वर्र्स में प्रारंभिक समस्याएं, उदाहरण के लिए, या स्मृति आवंटन / संरेखण)

अंत में, जैसा कि अन्य ने कहा, आप दोनों का उपयोग कर सकते हैं। कुछ वास्तविक समय-आश समस्याओं को लगभग एक प्रिंट की आवश्यकता होती है, या कम से कम एक न्यायसंगत "* video_dbg = (is_good? '+': '-');" कहीं वीडियो मेमोरी में। मेरी उम्र दिखा रही है, यह डॉस के तहत थी :-)

TMTOWTDI


चूंकि आपने पॉइंटर्स को किताबों के लिए कहा है ... जहां तक ​​विंडोज डिबगिंग जाता है, जॉन रॉबिन्स के पास विंडोज डिबगिंग पर एक अच्छी किताब के कई संस्करण हैं:

माइक्रोसॉफ्ट .NET और माइक्रोसॉफ्ट विंडोज के लिए अनुप्रयोगों को डीबग करना

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


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


वीएसएनईटी डीबगिंग विंडोज़ पर मैं यही अधिक उपयोग करता हूं:

  • कॉल स्टैक, जो कि किसी और के कोड को समझने का एक शानदार तरीका भी है
  • स्थानीय और घड़ियां
  • तत्काल खिड़की, जो मूल रूप से एक सी # कंसोल है और मुझे परिवर्तनीय सामग्री बदलने, सामान शुरू करने आदि की अनुमति देता है।
  • एक रेखा को छोड़ने की क्षमता, अगले कथन को कहीं और निष्पादित करने के लिए सेट करें।
  • चरों पर होवर करने की क्षमता और टूल-टिप मुझे अपना मूल्य दिखाती है।

संक्षेप में, यह मुझे मेरे निष्पादन कोड की स्थिति का एक 360 डिग्री दृश्य देता है, न केवल एक छोटी सी खिड़की।

इस तरह की चीजें सिखाते हुए कभी भी एक पुस्तक नहीं मिली, लेकिन फिर, यह काफी सरल प्रतीत होता है, यह बहुत अधिक WYSIWYG है।


  • एक डीबगर एक चल रही प्रक्रिया से जुड़ा हो सकता है

  • डीबगर से थ्रेडेड कोड डीबग करना अक्सर आसान होता है


क्योंकि प्रिंट स्टेटमेंट के साथ बहु-थ्रेडेड अनुप्रयोगों को डीबग करने से आपको केले मिलेंगे। हां आप अभी भी प्रिंट स्टेटमेंट के साथ ऐसा कर सकते हैं लेकिन आपको उनमें से बहुत से लोगों की आवश्यकता होगी और बहु-थ्रेडेड निष्पादन को अनुकरण करने के लिए कथन के अनुक्रमिक प्रिंट को अनदेखा करने में काफी समय लगेगा।

दुर्भाग्यवश मानव मस्तिष्क केवल सिंगल-थ्रेडेड हैं।


एक printf पर एक डीबगर के लाभ ( नोट आईडीई डीबगर नहीं लेकिन किसी भी डीबगर )

  1. Watchpoints सेट कर सकते हैं। यह स्मृति भ्रष्टाचार खोजने के मेरे पसंदीदा तरीकों में से एक है

  2. एक बाइनरी डीबग कर सकते हैं जिसे आप इस समय पुन: संकलित नहीं कर सकते हैं

  3. एक बाइनरी डीबग कर सकते हैं जो recompile करने के लिए एक लंबा समय लगता है

  4. फ्लाई पर चर बदल सकते हैं

  5. फ्लाई पर फ़ंक्शन कॉल कर सकते हैं

  6. ऐसी समस्या नहीं है जहां डीबग स्टेटमेनेट्स फ्लेश नहीं किए जाते हैं और इसलिए समय समस्या को ठीक से डीबग नहीं किया जा सकता

  7. डिबगर्स कोर डंप के साथ मदद करते हैं, प्रिंट स्टेटमेंट्स '


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

जहां तक ​​सीखने के संसाधन जाते हैं, मैंने किसी भी का उपयोग नहीं किया है - मैं बस सभी मेनू और विकल्पों का पता लगाता हूं।


खैर एक और बात यह है कि यदि आप एक नई पुरानी परियोजना में शामिल हो जाते हैं और कोई भी वास्तव में नहीं जानता कि कोड क्या कर रहा है, तो आप वैरिएबल / ऑब्जेक्ट्स को प्रतिबिंबित करके डीबग नहीं कर सकते हैं ... b / c आपको पता नहीं है कि कौन सा कोड है बिल्कुल निष्पादित

मेरे काम पर मुझे बिल्कुल इस तरह की स्थिति का सामना करना पड़ रहा है और दृश्य XDebuging मुझे इस बारे में एक विचार प्राप्त करने में मदद करता है कि क्या हो रहा है और कहां है।

सादर

Raffael


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


मेरे अनुभव में, सरल प्रिंटआउट का एक बड़ा फायदा होता है जिसे कोई भी उल्लेख नहीं करता है।

आईडीई डीबगर के साथ समस्या यह है कि वास्तविक समय पर सबकुछ होता है। आपने कार्यक्रम को एक निश्चित समय पर रोक दिया है, फिर आप एक समय में चरणों के माध्यम से कदम उठाते हैं और यदि आप अचानक देखना चाहते हैं कि पहले क्या हुआ है तो वापस जाना असंभव है। यह हमारे मस्तिष्क के काम के साथ बाधाओं पर completley है। मस्तिष्क सूचना एकत्र करता है, और धीरे-धीरे एक oppinion बनाता है। ऐसा करने में कई बार घटनाओं को फिर से शुरू करना आवश्यक हो सकता है, लेकिन एक बार जब आप एक निश्चित बिंदु से आगे बढ़ गए हैं, तो आप वापस नहीं जा सकते।

इसके विपरीत, प्रिंटआउट / लॉगिंग की एक चयनित श्रृंखला आपको "अस्थायी घटनाओं का स्थानिक प्रक्षेपण" देती है। यह आपको क्या हुआ, इसकी एक पूरी कहानी देता है, और आप ऊपर और नीचे स्क्रॉल करके कई बार कई बार आसानी से जा सकते हैं। यह प्रश्नों का उत्तर देना आसान बनाता है जैसे "बी बी से पहले हुआ"। यह आपको उन पैटर्नों को देख सकता है जिन्हें आप खोज रहे हैं।

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

हालांकि, जब हम अधिक difficoult समस्याओं तक पहुंचते हैं जहां राज्य के क्रमिक परिवर्तन शामिल है। उदाहरण के लिए जहां एक एल्गोरिदम ने डेटा संरचना को दूषित कर दिया, जिससे बदले में एनोटर एल्गोरिदम विफल हो गया। या अगर हम "यह कितनी बार ऐसा करते हैं" जैसे सवालों का जवाब देना चाहते हैं, "चीजें क्रम में होती हैं और जिस तरह से मैं उन्हें कल्पना करता हूं"। इत्यादि। फिर "पुरानी fashined" लॉगिंग / प्रिंटआउट तकनीक का एक स्पष्ट फायदा है।

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

हाइब्रिड दृष्टिकोण भी हैं। उदाहरण के लिए, जब आप console.log (ऑब्जेक्ट) करते हैं तो आपको लॉग में डेटा-स्ट्रक्चर विजेट मिलता है जिसे आप विस्तृत रूप से विस्तृत और एक्सप्लोर कर सकते हैं। यह "मृत" टेक्स्ट लॉग पर कई बार स्पष्ट लाभ है।


बस एक आईडीई में एक कंसोल डीबगर बनाम printf और बनाम डीबगर की उपयोगी सुविधा का उल्लेख करना चाहता था।

आप एक रिमोट एप्लिकेशन (obvioustly, DEBUG मोड में संकलित) से संलग्न कर सकते हैं और POSIX tee उपयोगिता का उपयोग कर फ़ाइल में डीबगर आउटपुट डंप करने के अपने राज्य का निरीक्षण कर सकते हैं। Printf की तुलना में, आप रन-टाइम में राज्य को आउटपुट कहां चुन सकते हैं।

इससे मुझे बहुत मदद मिली जब मैं एक आक्रामक वातावरण में तैनात एडोब फ्लैश अनुप्रयोगों को डीबग कर रहा था। आपको केवल कुछ क्रियाओं को परिभाषित करने की आवश्यकता है जो प्रत्येक ब्रेकपॉइंट में आवश्यक स्थिति मुद्रित करें, fdb | tee output.log साथ कंसोल डीबगर शुरू करें fdb | tee output.log , और कुछ ब्रेकपॉइंट्स के माध्यम से चलना। इसके बाद आप विभिन्न प्रिंटपॉइंट्स में राज्य की पूरी तुलना करके लॉग प्रिंट कर सकते हैं और जानकारी का विश्लेषण कर सकते हैं।

दुर्भाग्यवश, यह सुविधा [फ़ाइल में लॉगिंग] शायद ही कभी जीयूआई डिबगर्स में उपलब्ध है, जिससे डेवलपर्स अपने सिर में वस्तुओं की स्थिति की तुलना कर सकते हैं।

वैसे, मेरी राय यह है कि किसी को डीबगर को देखने से पहले कहां और क्या डीबग करना चाहिए।


यहां एक बात है कि आप निश्चित रूप से "प्रिंट" कथन से डीबग नहीं कर सकते हैं, जो तब होता है जब कोई ग्राहक आपको मेमोरी डंप लाता है और कहता है "आपका प्रोग्राम क्रैश हो गया है, क्या आप मुझे बता सकते हैं क्यों?"


मैं लगभग 20 वर्षों तक विकास नहीं कर रहा हूं, लेकिन मुझे लगता है कि एक आईडीई / डीबगर का उपयोग करके मैं कर सकता हूं:

  • उन सभी प्रकार की चीज़ें देखें जिन्हें मैंने प्रिंट स्टेटमेंट में शामिल नहीं किया होगा
  • यह देखने के लिए कोड के माध्यम से कदम उठाएं कि क्या यह उस पथ से मेल खाता है जिसे मैंने सोचा था
  • कोड को कुछ शाखाएं लेने के लिए कुछ मानों पर चर सेट करें

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

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

साथ ही, डीबगर का उपयोग करते समय, आपको डिबगिंग समाप्त करने के बाद अपने सभी प्रिंट स्टेटमेंट को हटाना नहीं होगा।


असली प्रोग्रामर से यह असली सवाल भी है?

कोई भी जिसने प्रिंट स्टेटमेंट्स और आईडीई के साथ डीबगिंग के साथ 5 मिनट तक डिबगिंग बिताई - वह बिना पूछे ओसीसीयू को भी करेगा!


एक बात जो मुझे आश्चर्यचकित है मैंने किसी अन्य जवाब में नहीं देखा है कि 2 डीबगिंग विधियां पारस्परिक रूप से अनन्य नहीं हैं।

यदि आप मानक डीबगर का उपयोग कर रहे हैं (चाहे आईडीई आधारित है या नहीं) तो printf डिबगिंग काफी अच्छी तरह से काम कर सकती है। विशेष रूप से लॉगिंग फ्रेमवर्क के साथ ताकि आप ग्राहक समस्याओं का निदान करने में सहायता के लिए जारी किए गए उत्पाद में से सभी या अधिकतर छोड़ सकें।

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


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

It's not just debugging. An IDE helps you build better software faster in a lot of ways:

  • refactoring tools
  • intellisense to make api's more discoverable, or remind of exact spelling/case of familiar items(not much use if you've used the same system for 15 years, but that's rare)
  • save on typing by autocompleting variable and class names
  • find certain kinds of errors before you even start to compile
  • Automatically jump to variable/method/class declarations/definitions, even if they're not in the same file or folder.
  • Break on unhandled and handled exceptions

I could go on.


मेरे सर के ऊपर से चला गया:

  1. जटिल वस्तुओं को डिबग करना - डिबगर्स आपको किसी ऑब्जेक्ट के अंदरूनी हिस्सों में गहराई से कदम रखने की अनुमति देता है। यदि आपके ऑब्जेक्ट में, जटिल वस्तुओं की सरणी की एक सरणी है, तो प्रिंट स्टेटमेंट केवल आपको ही प्राप्त करेंगे।
  2. पिछले कोड को चरणबद्ध करने की क्षमता - डिबगर्स आपको पिछले कोड को छोड़ने की अनुमति भी देगा जिसे आप निष्पादित नहीं करना चाहते हैं। सच है, आप इसे मैन्युअल रूप से भी कर सकते हैं, लेकिन यह उतना ही अधिक कोड है जिसे आपको इंजेक्ट करना है।

मुझे व्यक्तिगत रूप से लगता है कि उत्तर उतना आसान है जितना कि "एक एकीकृत डीबगर / आईडीई आपको आदेशों में छिद्रण की आवश्यकता के बिना जल्दी से अलग-अलग जानकारी का धन देता है। जानकारी आपके सामने नहीं होती है, इसके बिना आपने यह नहीं बताया है कि तुम्हें दिखाने।

आसानी से जानकारी को पुनर्प्राप्त किया जा सकता है, यह केवल कमांड लाइन डीबगिंग, या "printf" डिबगिंग से बेहतर बनाता है।


  • एक आईडीई डीबगर आपको रन-टाइम पर चर के मानों को बदलने देता है।

  • एक आईडीई डीबगर आपको उन चर के मान को देखने देता है जिन्हें आप नहीं जानते थे कि आप कब देखना चाहते थे कि निष्पादन कब शुरू हुआ था।

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

  • एक आईडीई डीबगर आपको एक शर्त के आधार पर कोड में किसी भी बिंदु पर निष्पादन को सशर्त रूप से तोड़ने देता है, न कि लाइन नंबर।

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





ide