मैं समझता हूं कि try और catch() अपवाद हैंडलिंग के लिए उपयोग किया जाता है, केवल कुछ मामलों के तहत प्रोग्राम में कोई त्रुटि या क्रैश होने पर। मैं यह भी समझता हूं कि वे कैसे काम करते हैं। लेकिन try और catch() का उपयोग क्यों करें? क्यों न केवल if() कथन का उपयोग करें जो एक निश्चित मामले की तलाश में है और यदि यह मामला सत्य है, तो यह cout << //error code है?सी ++ में कोशिश करें और पकड़ें() का उपयोग क्यों करें?
अपवाद संचालन:
X - नोटेशन x1 = x2 + x3 - whe का समर्थन करता है एक त्रुटि कोड वापस किया जा सकता है?-1 "अपने स्वयं के ढेर का उपयोग करें जिसका मतलब है कि त्रुटि प्रबंधन स्टैक-ओवरफ्लो परिदृश्यों में विश्वसनीय हो सकता है" [बुलशिट] (http://en.wikipedia.org/wiki/Bullshit#Distinguished_from_lying) –
@ चीयर्संधथ-अल्फ: ए तकनीकी दावे से संबंधित कुछ चीज़ों से लिंक जो आप ऑब्जेक्ट कर रहे हैं उससे अधिक उपयोगी है, आप हमें "बुलशिट" –
के बारे में कुछ कथित बारीकियों के साथ प्रभावित करने की कोशिश कर रहे हैं, जो आपके कथन का उपयोग करते हैं, जिसका मतलब है कि त्रुटि प्रबंधन स्टैक-ओवरफ्लो परिदृश्य में भरोसेमंद "शुद्ध बैलशिट है। सी ++ अपवाद हैंडलिंग अपने स्वयं के ढेर का उपयोग नहीं करती है, और यह सार्थक नहीं है। यह ढेर अतिप्रवाह स्थितियों में भरोसेमंद नहीं है: भाषा उस स्थिति के लिए कोई गारंटी नहीं देती है। संक्षेप में, फिर से , यह पूरी तरह से बकवास है। एक फंतासी ** ** एक तकनीकी कथन के लिए फॉर्म में **, लेकिन जहां सामग्री है - बस बुलशिट। –
try...catch और भी कुछ करता है। यह स्टैक को अनदेखा करता है जो try दर्ज होने के बाद सभी स्वचालित आवंटित ऑब्जेक्ट्स के लिए विनाशकों को बुलाता है। आप इसे आपके द्वारा सुझाए गए तरीके से करना यदि आप मैन्युअल रूप से इन वस्तु का ट्रैक रखने करना होगा या आप मिल जाएगा स्मृति मुद्दों (लीक, अधिलेखित, बासी संकेत दिए गए, डबल हटाता है)
यह बिल्कुल सही नहीं है ... यदि फ़ंक्शन अपवादों के बजाय त्रुटि कोड लौटाते हैं, तो कॉलर में 'if (error) return' तर्क भी उसी विनाशकों को आक्रमण करने में त्रुटि को बुलबुला करेगा। यदि ऐसे कच्चे पॉइंटर्स हैं जिन्हें हटाने की आवश्यकता है, अपवाद जादूगर रूप से उस डेलोकेशन की व्यवस्था नहीं करेंगे। –
यह वास्तव में सच है। 'कोशिश करें ... पकड़ो' कथन के बिना, अपवाद फेंकने से ढेर को खारिज नहीं किया जा सकता है। (15.5.1) – MSalters
@MSalters: बेशक यह सच है कि अपवादों को फेंक दिया जा सकता है, लेकिन सवाल पूछ रहा है "क्यों एक निश्चित मामले की तलाश में एक if() कथन का उपयोग न करें और यदि यह मामला सच है, तो यह cout करता है << // त्रुटि कोड? "... दूसरे शब्दों में, सी-स्टाइल रिटर्न कोड प्रचार ... और इसकी तुलना में विशेष रूप से" कोशिश करें ... पकड़ अधिक करता है "सच नहीं है। –
मैं अपने नायकों में से एक उद्धरण के साथ उत्तर देने जा रहा हूं, ज़ीरोएमक्यू प्रसिद्धि के मार्टिन सूस्ट्रिक, http://www.250bpm.com/blog:4
पर ब्लॉग प्रविष्टि हालांकि, सीधा विफलताओं से बचने के लिए बहुत अच्छा है एक बुरा सपना हो जाता है अपने लक्ष्य गारंटी नहीं है कि कोई अपरिभाषित व्यवहार होता है जब। अपवाद को बढ़ाने और इसे संभालने के बीच decoupling, जो सी ++ में विफलताओं से बचने में विफल बनाता है, यह गारंटी देने के लिए लगभग असंभव बनाता है कि कार्यक्रम कभी भी अपरिभाषित व्यवहार को नहीं चलाता है।
और फिर जोड़ें, मुझे लगता है कि मैं बहुत अधिक लीवर रीस्टार्ट परतों के लिए प्रयास/पकड़ का उपयोग करता हूं, और कुछ भी नहीं। जोड़ना, कि मेरी राय वास्तव में कोई फर्क नहीं पड़ता। मुझे विश्वास है कि अपवाद हैंडलिंग का उपयोग करने के तरीके के पीछे विकल्प विकल्प के समान है जो नीले रंग से अधिक हरे रंग की पसंद करता है। व्यक्तिगत, और दूसरों से कोई इनपुट कभी भी इसे बदलने की संभावना नहीं है।
बकवास उद्धरण। यूबी के कारण अपवादों का कोई कारण नहीं है, और यूबी को रोकने का एक महत्वपूर्ण कारण है: वे कोड के उन हिस्सों से त्वरित बाहर निकलने का कारण बनते हैं जो आपके डेटा के साथ असंगत हैं। – MSalters
+1 काउंटर (कम से कम 2) अनदेखा डाउनवॉट्स का मुकाबला करने के लिए। –
दूसरा कारण यह है कि: आपके द्वारा लिखे गए कोड को किसी और द्वारा बड़ी परियोजना के हिस्से के रूप में भी इस्तेमाल किया जा सकता है। और अंतर्निहित अपवाद-हैंडलिंग दिनचर्या का उपयोग करने के बाद से एक मानक है, बड़े प्रोजेक्ट के रखरखावकर्ता उम्मीद कर रहे हैं कि आप अपने अपवादों को इसी प्रकार संभाल लेंगे, ताकि अपवाद हैंडलिंग को ऊपरी स्तर पर ठीक से पूरा किया जा सके - तथ्य की बात न करें कि मानक का उपयोग करना एक आउटपुट आउटपुट के रूप में आउटपुट एक संदिग्ध अभ्यास है (इसे दबाया जा सकता है, उदाहरण के लिए, या बिल्कुल इस्तेमाल नहीं किया जा सकता है)।
यूपीडी: मैंने आपके प्रश्न को थोड़ा सा गलत समझा। मैंने वर्णित कारण वास्तव में मैन्युअल अपवाद फेंकने को सही ठहराया है, लेकिन try...catch ब्लॉक का उपयोग नहीं कर रहा है।
प्रश्न झूठी डिचोटोमी बन गया है। जावा और सी # try - catch विफलता पर सफाई के लिए if के साथ प्रतिस्पर्धा करता है। सी ++ में यह मुख्य रूप से आरएआईआई तकनीक (विनाशकों और एकल चरण निर्माण का उपयोग करके) है जो विफलता पर सफाई के लिए if के साथ प्रतिस्पर्धा करता है।
यदि प्रश्न if का उपयोग कर अपवादों का उपयोग करने के बारे में किया गया था, तो यह सामान्य सी ++ प्रोग्रामिंग के लिए अधिक समझदार और प्रासंगिक होता।
"यदि प्रश्न बनाम अपवादों का उपयोग करने के बारे में सवाल किया गया था, तो [समझदार]" - यह सवाल से काफी अलग कैसे है: "... कोशिश क्यों करें और पकड़ें()? क्यों एक if() का उपयोग न करें। .. "? –
@ टोनीडी: आप उस उत्तर को पढ़ सकते हैं जिस पर आप टिप्पणी कर रहे हैं। –
आप जानते हैं, अजीब बात है, मैंने किया था। लेकिन, जावा और सी # के साथ तुलना (जिनमें से कोई भी प्रश्न या टैग में उल्लिखित नहीं था) संभावित श्रोताओं के लिए इसे समझने के लिए सेट नहीं करता है। वैसे भी, अगर यह आपके लिए काम करता है और आपके पास कहने के लिए और कुछ नहीं है, तो यह मेरे द्वारा ठीक है। –
'try' कीवर्ड से जुड़े कोई भी ब्रांड्स नहीं हैं। वास्तव में, 'पकड़' हमेशा यह नहीं होता है, या तो। –
@ मार्सेलो कैंटोस: "वास्तव में, पकड़ में हमेशा [कोष्ठक] नहीं होता है," या हाँ यह करता है - एस 15.1 से: "हैंडलर: पकड़ (अपवाद-घोषणा) यौगिक-कथन" - कोई अन्य कानूनी नहीं है वाक्य - विन्यास। –
@ मार्सेलो कैंटोस मैंने इसे ठीक किया, सुधार के लिए धन्यवाद – aanrv