अपवादों को रूढ़िवादी रूप से क्यों इस्तेमाल किया जाना चाहिए?

Question 1

मैं अक्सर लोगों को कहता / सुनता हूं कि अपवादों का उपयोग केवल शायद ही कभी किया जाना चाहिए, लेकिन कभी भी क्यों नहीं समझाएं। हालांकि यह सच हो सकता है, औचित्य सामान्य रूप से एक glib है: "इसे एक कारण के लिए एक अपवाद कहा जाता है" , जो मुझे, एक स्पष्टीकरण के प्रकार लगता है जिसे कभी भी एक सम्मानित प्रोग्रामर / इंजीनियर द्वारा स्वीकार नहीं किया जाना चाहिए।

समस्याओं की एक श्रृंखला है जिसे हल करने के लिए एक अपवाद का उपयोग किया जा सकता है। नियंत्रण प्रवाह के लिए उनका उपयोग करना नासमझी क्यों है? उनके उपयोग के साथ असाधारण रूढ़िवादी होने के पीछे दर्शन क्या है? शब्दार्थ? प्रदर्शन? जटिलता? सौंदर्यशास्त्र? कन्वेंशन?

मैंने पहले प्रदर्शन पर कुछ विश्लेषण देखा है, लेकिन एक स्तर पर जो कुछ प्रणालियों के लिए प्रासंगिक होगा और दूसरों के लिए अप्रासंगिक।

फिर, मैं जरूरी नहीं असहमत हूं कि उन्हें विशेष परिस्थितियों के लिए बचाया जाना चाहिए, लेकिन मैं सोच रहा हूं कि सर्वसम्मति का तर्क क्या है (यदि ऐसा कुछ मौजूद है)।

Question 2

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

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

सीधे अपने सवाल का जवाब। अपवादों का उपयोग शायद ही कभी किया जाना चाहिए क्योंकि असाधारण स्थितियां दुर्लभ हैं और अपवाद महंगे हैं।

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

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

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

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

नियंत्रण प्रवाह के लिए उनका उपयोग करना नासमझ क्यों है?

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

कहते हैं, आप एक विधि M () कॉल विधि N () चाहते थे कि कुछ काम करें और कुछ संसाधन की व्यवस्था करें और फिर इसे M () में वापस लौटाएं जो इसका उपयोग करेगा और फिर इसका निपटान करेगा। ठीक। अब N () में कुछ गलत हो जाता है और यह एक अपवाद को फेंक देता है जिसकी आप M में उम्मीद नहीं करते थे () इसलिए शीर्ष बुलबुले को तब तक छोड़ते हैं जब तक कि यह शायद किसी विधि C () में न फंस जाए, जिसे पता नहीं चलेगा कि नीचे क्या हो रहा है एन में () और क्या और कैसे कुछ संसाधनों को मुक्त करने के लिए।

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

Question 3

जबकि "असाधारण cirumstances में फेंक अपवाद" glib जवाब है, आप वास्तव में परिभाषित कर सकते हैं कि उन परिस्थितियों क्या हैं: जब पूर्व शर्त संतुष्ट हैं, लेकिन पोस्टकंडिशन संतुष्ट नहीं हो सकते । यह आपको त्रुटि-हैंडलिंग का त्याग किए बिना कठोर, तंग और अधिक उपयोगी पोस्टकॉन्डिशन लिखने की अनुमति देता है; अन्यथा, अपवादों के बिना, आपको हर संभव त्रुटि स्थिति के लिए पोस्टकंडिशन को बदलना होगा।

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

कंस्ट्रक्टर्स

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

एक अपवाद को फेंकने का एकमात्र विकल्प जब एक निर्माता सफल नहीं हो सकता है, तो मान्य "शून्य" या ज़ोंबी राज्यों की अनुमति देने के लिए वर्ग की मूल परिभाषा ("वर्ग अपरिवर्तनीय") को संशोधित करना और इस तरह एक ज़ोंबी का निर्माण करके निर्माता को "सफल" होने दें। ।

ज़ोंबी उदाहरण

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

string s = "abc";
if (s.memory_allocation_succeeded()) {
  do_something_with(s); // etc.
}

यहां तक कि उस विधि का नामकरण इस बात का एक अच्छा उदाहरण है कि कैसे आप एक स्थिति स्ट्रिंग के लिए वर्ग के अपरिवर्तनीय और इंटरफ़ेस को संशोधित करना चाहिए और न ही भविष्यवाणी कर सकते हैं और न ही संभाल सकते हैं।

इनपुट उदाहरण को मान्य करना

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

// boost::lexical_cast<int>() is the parsing function here
void show_square() {
  using namespace std;
  assert(cin); // precondition for show_square()
  cout << "Enter a number: ";
  string line;
  if (!getline(cin, line)) { // EOF on cin
    // error handling omitted, that EOF will not be reached is considered
    // part of the precondition for this function for the sake of example
    //
    // note: the below Python version throws an EOFError from raw_input
    //  in this case, and handling this situation is the only difference
    //  between the two
  }
  int n;
  try {
    n = boost::lexical_cast<int>(line);
    // lexical_cast returns an int
    // if line == "abc", it obviously cannot meet that postcondition
  }
  catch (boost::bad_lexical_cast&) {
    cout << "I can't do that, Dave.\n";
    return;
  }
  cout << n * n << '\n';
}

दुर्भाग्य से, यह दो उदाहरण दिखाता है कि C ++ की स्कूपिंग के लिए आपको RAII / SBRM को कैसे तोड़ना है। पायथन में एक उदाहरण है जिसमें वह समस्या नहीं है और कुछ ऐसा दिखाता है जो मेरी इच्छा है कि C ++ के पास है - प्रयास करें:

# int() is the parsing "function" here
def show_square():
  line = raw_input("Enter a number: ") # same precondition as above
  # however, here raw_input will throw an exception instead of us
  # using assert
  try:
    n = int(line)
  except ValueError:
    print "I can't do that, Dave."
  else:
    print n * n

पूर्व शर्त

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

विशेष रूप से, एसटीडी के विपरीत :: लॉजिक_रोर और एसटी :: रनटाइम_रोर शाखाओं की स्टडलिब अपवाद हॉररसे। पूर्व का उपयोग अक्सर पूर्व-उल्लंघन के उल्लंघन के लिए किया जाता है, जबकि उत्तरार्द्ध बाद के उल्लंघन के लिए अधिक अनुकूल है।

Question 4

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

Question 5

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

Question 6

अपवाद आपके कार्यक्रम की स्थिति के बारे में तर्क करना कठिन बनाते हैं। उदाहरण के लिए C ++ में, आपको यह सुनिश्चित करने के लिए अतिरिक्त सोच-विचार करना होगा कि आपके कार्य दृढ़ता से सुरक्षित हैं, यदि आपको उनकी आवश्यकता नहीं है, तो आपको करना होगा।

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

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

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

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

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

Question 7

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

C ++ प्रोग्रामर के रूप में, मैं व्यक्तिगत रूप से बहुत ही "असाधारण" परिस्थितियों के लिए अपवादों को आरक्षित करना पसंद करता हूं, उदाहरण के लिए मेमोरी से बाहर, डिस्क-स्पेस से, सर्वनाश हुआ, आदि। लेकिन मैं जोर नहीं देता कि यह करने का पूर्ण सही तरीका है चीजें।

Question 8

मुझे नहीं लगता, कि अपवादों का उपयोग शायद ही कभी किया जाना चाहिए। परंतु।

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

यदि आप अपवादों का बड़े पैमाने पर उपयोग करने जा रहे हैं, तो:

अपने लोगों को यह सिखाने के लिए तैयार रहें कि अपवाद सुरक्षा क्या है
आपको कच्चे स्मृति प्रबंधन का उपयोग नहीं करना चाहिए
बड़े पैमाने पर RAII का उपयोग करें

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

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

Question 9

EDIT 11/20/2009 :

मैं प्रबंधित कोड प्रदर्शन को बेहतर बनाने के लिए MSDN के इस लेख को पढ़ रहा था और इस हिस्से ने मुझे इस प्रश्न की याद दिला दी:

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

बेशक, यह केवल .NET के लिए है, और यह विशेष रूप से उन उच्च-प्रदर्शन अनुप्रयोगों को विकसित करने के लिए भी निर्देशित है (जैसे स्वयं); इसलिए यह स्पष्ट रूप से एक सार्वभौमिक सत्य नहीं है। फिर भी, वहाँ हम में से बहुत सारे .NET डेवलपर्स हैं, इसलिए मुझे लगा कि यह ध्यान देने योग्य है।

संपादित करें :

ठीक है, सबसे पहले, चलो एक बात सीधे करें: प्रदर्शन के सवाल पर मेरा किसी से झगड़ा करने का कोई इरादा नहीं है। सामान्य तौर पर, वास्तव में, मैं उन लोगों से सहमत होने के लिए इच्छुक हूं जो मानते हैं कि समय से पहले अनुकूलन एक पाप है। हालाँकि, मुझे सिर्फ दो बिंदु बनाने हैं:

पोस्टर पारंपरिक ज्ञान के पीछे एक उद्देश्यपूर्ण तर्क के लिए कह रहा है कि अपवादों को संयम से इस्तेमाल किया जाना चाहिए। हम पठनीयता और उचित डिज़ाइन पर चर्चा कर सकते हैं जो हम चाहते हैं; लेकिन ये दोनों तरफ से बहस करने के लिए तैयार लोगों के साथ व्यक्तिपरक मामले हैं। मुझे लगता है कि पोस्टर से इस बारे में पता चलता है। तथ्य यह है कि कार्यक्रम प्रवाह को नियंत्रित करने के लिए अपवादों का उपयोग करना अक्सर चीजों को करने का एक अक्षम तरीका है। नहीं, हमेशा नहीं , लेकिन अक्सर । यही कारण है कि यह उचित सलाह है कि अपवादों का संयम से उपयोग करें, ठीक उसी तरह जैसे कि लाल मांस खाने या शराब पीने से बचना अच्छी सलाह है।
बिना किसी अच्छे कारण के अनुकूलन करने और कुशल कोड लिखने के बीच अंतर है। इस के लिए कोरलरी यह है कि कुछ लिखने के बीच अंतर है जो मजबूत है, अगर अनुकूलित नहीं है, और कुछ ऐसा है जो सिर्फ सादा अक्षम है। कभी-कभी मुझे लगता है कि जब लोग अपवाद की तरह की चीजों पर बहस करते हैं, तो वे वास्तव में सिर्फ एक-दूसरे से बात कर रहे होते हैं, क्योंकि वे मौलिक रूप से अलग-अलग चीजों पर चर्चा कर रहे होते हैं।

मेरी बात को समझाने के लिए, निम्नलिखित C # कोड उदाहरणों पर विचार करें।

उदाहरण 1: अमान्य उपयोगकर्ता इनपुट का पता लगाना

यह एक उदाहरण है कि मैं अपवाद दुरुपयोग क्या कहूंगा ।

int value = -1;
string input = GetInput();
bool inputChecksOut = false;

while (!inputChecksOut) {
    try {
        value = int.Parse(input);
        inputChecksOut = true;

    } catch (FormatException) {
        input = GetInput();
    }
}

यह कोड मेरे लिए हास्यास्पद है। बेशक यह काम करता है । उसके साथ किसी की बहस नहीं हुई। लेकिन यह कुछ इस तरह होना चाहिए :

int value = -1;
string input = GetInput();

while (!int.TryParse(input, out value)) {
    input = GetInput();
}

उदाहरण 2: फ़ाइल के अस्तित्व की जाँच करना

मुझे लगता है कि यह परिदृश्य वास्तव में बहुत सामान्य है। यह निश्चित रूप से बहुत अधिक लोगों को "स्वीकार्य" लगता है, क्योंकि यह फ़ाइल I / O से संबंधित है:

string text = null;
string path = GetInput();
bool inputChecksOut = false;

while (!inputChecksOut) {
    try {
        using (FileStream fs = new FileStream(path, FileMode.Open)) {
            using (StreamReader sr = new StreamReader(fs)) {
                text = sr.ReadToEnd();
            }
        }

        inputChecksOut = true;

    } catch (FileNotFoundException) {
        path = GetInput();
    }
}

यह उचित पर्याप्त लगता है, है ना? हम एक फ़ाइल खोलने की कोशिश कर रहे हैं; अगर यह नहीं है, तो हम उस अपवाद को पकड़ लेते हैं और एक अलग फाइल खोलने की कोशिश करते हैं ... इसमें गलत क्या है?

कुछ भी सच नहीं। लेकिन इस विकल्प पर विचार करें, जिसमें कोई अपवाद नहीं है:

string text = null;
string path = GetInput();

while (!File.Exists(path)) path = GetInput();

using (FileStream fs = new FileStream(path, FileMode.Open)) {
    using (StreamReader sr = new StreamReader(fs)) {
        text = sr.ReadToEnd();
    }
}

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

का उपयोग कर try/ catchब्लॉक : 25.455 सेकंड
का उपयोग कर int.TryParse: 1.637 मिलीसेकंड

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

का उपयोग कर try/ catchब्लॉक: 29.989 सेकंड
का उपयोग करना File.Exists: 22.820 मिलीसेकंड

बहुत से लोग इस पर प्रतिक्रिया देते हुए कहते हैं, "हाँ, ठीक है, 10,000 अपवादों को फेंकना और पकड़ना बेहद अवास्तविक है; इससे परिणाम अतिरंजित होते हैं।" बिलकुल यह करता है। एक अपवाद को फेंकने और अपने आप पर खराब इनपुट को संभालने के बीच का अंतर उपयोगकर्ता के लिए ध्यान देने योग्य नहीं है। तथ्य यह है कि अपवादों का उपयोग करते हुए, इन दो मामलों में, 1,000 से 10,000 गुना अधिक वैकल्पिक दृष्टिकोणों की तुलना में धीमा है जो कि केवल पठनीय हैं - यदि ऐसा नहीं है।

इसलिए मैंने GetNine()नीचे दी गई विधि का उदाहरण शामिल किया । ऐसा नहीं है कि यह असहिष्णु रूप से धीमा है या अस्वीकार्य रूप से धीमा है; यह है कि यह धीमी गति से होना चाहिए ... बिना किसी अच्छे कारण के ।

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

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

ठीक है, शायद यह आपके विशेष रूप से व्यावसायिक परिदृश्य के लिए ठीक है, लेकिन अपेक्षाकृत बोलना , फेंकना / पकड़ना एक तरह से अधिक ओवरहेड का परिचय देता है, कई मामलों में आवश्यक है। आप इसे जानते हैं, मैं इसे जानता हूं: अधिकांश समय , यदि आप प्रोग्राम प्रवाह को नियंत्रित करने के लिए अपवादों का उपयोग कर रहे हैं, तो आप केवल धीमी कोड लिख रहे हैं।

आप यह भी पूछ सकते हैं: यह कोड खराब क्यों है?

private int GetNine() {
    for (int i = 0; i < 10; i++) {
        if (i == 9) return i;
    }
}

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

जब लोग अपवाद के बारे में बात करते हैं तो इसका मतलब है "दुरुपयोग।"

Question 10

अपवादों के बारे में अंगूठे के सभी नियम व्यक्तिपरक शब्दों के नीचे आते हैं। आप का उपयोग करने के लिए जब नहीं करने के लिए कठिन और तेजी से परिभाषाएँ प्राप्त करने की उम्मीद करनी चाहिए। "केवल असाधारण परिस्थितियों में"। अच्छी परिपत्र परिभाषा: अपवाद असाधारण परिस्थितियों के लिए हैं।

जब अपवाद का उपयोग करने के लिए एक ही बाल्टी में गिर जाता है "मुझे कैसे पता चलेगा कि यह कोड एक वर्ग है या दो?" यह आंशिक रूप से एक शैलीगत मुद्दा है, आंशिक रूप से एक प्राथमिकता है। अपवाद एक उपकरण है। उनका उपयोग किया जा सकता है और दुरुपयोग किया जा सकता है, और दोनों के बीच की रेखा को खोजने और प्रोग्रामिंग की कला और कौशल का हिस्सा है।

बहुत सारी राय है, और ट्रेडऑफ बनाया जाना है। कोई ऐसी चीज खोजें, जो आपसे बोलती हो, और उसका पालन करें।

Question 11

ऐसा नहीं है कि अपवादों का उपयोग शायद ही कभी किया जाना चाहिए। यह सिर्फ इतना है कि उन्हें केवल असाधारण परिस्थितियों में फेंक दिया जाना चाहिए। उदाहरण के लिए, यदि कोई उपयोगकर्ता गलत पासवर्ड दर्ज करता है, तो यह असाधारण नहीं है।

कारण सरल है: अपवाद अचानक एक फ़ंक्शन से बाहर निकलते हैं, और स्टैक को एक catchब्लॉक तक प्रचारित करते हैं । यह प्रक्रिया बहुत कम्प्यूटेशनल रूप से महंगी है: C ++ अपने अपवाद सिस्टम को "सामान्य" फ़ंक्शन कॉल पर बहुत अधिक ओवरहेड बनाने के लिए बनाता है, इसलिए जब कोई अपवाद उठाया जाता है, तो यह जानने के लिए बहुत काम करना पड़ता है कि कहां जाना है। इसके अलावा, कोड की हर पंक्ति संभवतः एक अपवाद बढ़ा सकती है। यदि हमारे पास कुछ फ़ंक्शन हैं fजो अक्सर अपवादों को उठाते हैं, तो हमें अब हर कॉल के आसपास हमारे try/ catchब्लॉकों का उपयोग करने के लिए ध्यान रखना होगा f। यह एक बहुत बुरा इंटरफ़ेस / कार्यान्वयन युग्मन है।

Question 12

मैंने C ++ अपवादों पर एक लेख में इस मुद्दे का उल्लेख किया ।

प्रासंगिक हिस्सा:

लगभग हमेशा, "सामान्य" प्रवाह को प्रभावित करने के लिए अपवादों का उपयोग करना एक बुरा विचार है। जैसा कि हमने पहले ही खंड 3.1 में चर्चा की है, अपवाद अदृश्य कोड पथ उत्पन्न करते हैं। ये कोड पथ यकीनन स्वीकार्य हैं यदि वे केवल त्रुटि हैंडलिंग परिदृश्यों में निष्पादित होते हैं। हालांकि, अगर हम किसी अन्य उद्देश्य के लिए अपवादों का उपयोग करते हैं, तो हमारे "सामान्य" कोड निष्पादन को एक दृश्य और अदृश्य भाग में विभाजित किया गया है और यह कोड को पढ़ने, समझने और विस्तारित करने के लिए बहुत कठिन बनाता है।

Question 13

त्रुटि से निपटने के लिए मेरा दृष्टिकोण यह है कि तीन मूलभूत प्रकार की त्रुटियाँ हैं:

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

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

Question 14

मैंने यहाँ कुछ उत्तर पढ़े। मैं अभी भी चकित हूं कि यह सब भ्रम किस बारे में है। मैं इन सभी अपवादों से असहमत हूं == स्पेगेटी कोड। भ्रम के साथ मेरा मतलब है, कि ऐसे लोग हैं, जो C ++ अपवाद हैंडलिंग की सराहना नहीं करते हैं। मैं निश्चित नहीं हूं कि मैंने C ++ अपवाद हैंडलिंग के बारे में कैसे सीखा - लेकिन मैंने मिनटों में निहितार्थ को समझ लिया। यह 1996 के आसपास था और मैं ओएस / 2 के लिए बोरलैंड C ++ कंपाइलर का उपयोग कर रहा था। मुझे कभी भी यह तय करने की समस्या नहीं थी कि अपवादों का उपयोग कब करना है। मैं आमतौर पर C ++ कक्षाओं में फॉलिबल डू-अनडू एक्शन को लपेटता हूं। ऐसी गतिविधियों को पूर्ववत करें:

सिस्टम हैंडल को बनाना / नष्ट करना (फाइलों, मेमोरी मैप्स, WIN32 GUI हैंडल, सॉकेट्स आदि के लिए)
सेटिंग / परेशान करने वाले हैंडलर
स्मृति आवंटित करना / डील करना
म्यूटेक्स का दावा / विमोचन
incrementing / decrementing एक संदर्भ गणना
विंडो दिखाना / छिपाना

वहाँ कार्यात्मक रैपर हैं। सिस्टम कॉल को लपेटने के लिए (जो पूर्व श्रेणी में नहीं आते हैं) C ++ में। जैसे फ़ाइल से / से पढ़ना / लिखना। यदि कुछ विफल होता है, तो एक अपवाद फेंक दिया जाएगा, जिसमें त्रुटि के बारे में पूरी जानकारी है।

फिर विफलता में अधिक जानकारी जोड़ने के लिए अपवादों को पकड़ना / पुनर्विचार करना है।

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

एक ऐसे वर्गों को जटिल कक्षाओं में श्रृंखलाबद्ध कर सकता है। एक बार किसी सदस्य / बेस ऑब्जेक्ट के एक कंस्ट्रक्टर को एक्सट्रैक्ट किया जाता है, तो कोई भी उस ऑब्जेक्ट के अन्य सभी कंस्ट्रक्टरों (पहले निष्पादित) सफलतापूर्वक निष्पादित कर सकता है, इस पर भरोसा कर सकता है।

Question 15

अपवाद पारंपरिक निर्माणों की तुलना में प्रवाह नियंत्रण की एक बहुत ही असामान्य विधि है (छोरों, अगर, कार्य, आदि) सामान्य नियंत्रण प्रवाह निर्माण (छोरों, अगर, फ़ंक्शन कॉल, आदि) सभी सामान्य स्थितियों को संभाल सकते हैं। यदि आप अपने आप को एक नियमित घटना के अपवाद के लिए पहुंचते हैं, तो शायद आपको यह विचार करने की आवश्यकता है कि आपका कोड कैसे संरचित है।

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

यदि कोई क्लाइंट ParseIntस्ट्रिंग के साथ कॉल करता है, और स्ट्रिंग में पूर्णांक नहीं है, तो तत्काल कॉलर संभवतः त्रुटि के बारे में परवाह करता है और जानता है कि इसके बारे में क्या करना है। तो आप ParseInt को इस तरह से कुछ के लिए एक विफलता कोड वापस करने के लिए डिज़ाइन करेंगे।

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

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

Question 16

C ++ में कई कारण हैं।

सबसे पहले, यह देखना अक्सर कठिन होता है कि अपवाद कहां से आ रहे हैं (क्योंकि उन्हें लगभग किसी भी चीज से फेंका जा सकता है) और इसलिए कैच ब्लॉक एक COME FROM स्टेटमेंट में से कुछ है। यह GO TO से भी बदतर है, क्योंकि GO में आपको पता है कि आप कहां से आ रहे हैं (स्टेटमेंट, कुछ रैंडम फंक्शन कॉल नहीं) और आप कहां जा रहे हैं (लेबल)। वे मूल रूप से C के सेटजम्प () और लॉन्गजम्प () का संभावित संसाधन-सुरक्षित संस्करण हैं, और कोई भी उनका उपयोग नहीं करना चाहता है।

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

तीसरा, C ++ समुदाय, जिसमें बज़्ने स्ट्रॉस्ट्रुप और मानक समिति और विभिन्न संकलक लेखक शामिल हैं, यह मानते रहे हैं कि अपवाद असाधारण होना चाहिए। सामान्य तौर पर, यह भाषा संस्कृति के खिलाफ जाने लायक नहीं है। कार्यान्वयन इस धारणा पर आधारित हैं कि अपवाद दुर्लभ होंगे। बेहतर किताबें अपवादों को असाधारण मानती हैं। अच्छा स्रोत कोड कुछ अपवादों का उपयोग करता है। अच्छा C ++ डेवलपर्स अपवादों को असाधारण मानते हैं। उस के खिलाफ जाने के लिए, आप एक अच्छा कारण चाहते हैं, और मेरे द्वारा देखे जाने वाले सभी कारण उन्हें असाधारण रखने के पक्ष में हैं।

Question 17

यह नियंत्रण प्रवाह के रूप में अपवादों का उपयोग करने का एक बुरा उदाहरण है:

int getTotalIncome(int incomeType) {
   int totalIncome= 0;
   try {
      totalIncome= calculateIncomeAsTypeA();
   } catch (IncorrectIncomeTypeException& e) {
      totalIncome= calculateIncomeAsTypeB();
   }

   return totalIncome;
}

जो बहुत बुरा है, लेकिन आपको लिखना चाहिए:

int getTotalIncome(int incomeType) {
   int totalIncome= 0;
   if (incomeType == A) {
      totalIncome= calculateIncomeAsTypeA();
   } else if (incomeType == B) {
      totalIncome= calculateIncomeAsTypeB();
   }
   return totalIncome;
}

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

अपवादों में कुछ प्रदर्शन दंड भी जुड़े होते हैं, लेकिन प्रदर्शन की समस्याओं को नियम का पालन करना चाहिए: "समय से पहले अनुकूलन सभी बुराई की जड़ है"

Question 18

रखरखाव: जैसा कि ऊपर लोगों द्वारा उल्लेख किया गया है, एक टोपी के एक बूंद पर अपवादों को फेंकना गोटो का उपयोग करने के समान है।
इंटरऑपरेबिलिटी: यदि आप अपवादों का उपयोग कर रहे हैं, तो आप C / Python मॉड्यूल (कम से कम आसानी से नहीं) के साथ C ++ पुस्तकालयों को इंटरफ़ेस नहीं कर सकते।
प्रदर्शन में गिरावट: आरटीटीआई का उपयोग वास्तव में अपवाद के प्रकार को खोजने के लिए किया जाता है जो अतिरिक्त ओवरहेड लगाता है। इस प्रकार अपवाद आमतौर पर होने वाले उपयोग के मामलों को संभालने के लिए उपयुक्त नहीं हैं (उपयोगकर्ता स्ट्रिंग आदि के बजाय इंट में प्रवेश करते हैं)।

Question 19

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

Question 20

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

इसके अलावा, यह कुख्यात "कैच थ्रो" जैसे कुछ विरोधी पैटर्न की ओर जाता है और वास्तविक समस्याओं को रोकता है। उस विषय पर अधिक जानकारी के लिए मैं इस विषय पर एक ब्लॉग पोस्ट देखें ।

Question 21

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

इसके लिए काउंटर तर्क यह है कि आलसी लोगों को अपने पैरों में खुद को गोली मारने के लिए अधिक टाइप करने की आवश्यकता होती है।

Google की कोडिंग नीति यह कहती है कि अपवादों का उपयोग कभी न करें , विशेषकर C ++ में। आपका आवेदन या तो अपवादों को संभालने के लिए तैयार नहीं है या यह है। यदि ऐसा नहीं है, तो अपवाद शायद तब तक इसे प्रचारित करेगा जब तक कि आपके आवेदन की मृत्यु नहीं हो जाती।

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

Question 22

अपवाद फेंकने के लिए वैध मामला:

आप एक फ़ाइल खोलने की कोशिश करते हैं, यह वहां नहीं है, एक FileNotFoundException को फेंक दिया गया है;

अवैध मामला:

आप केवल कुछ करना चाहते हैं यदि कोई फ़ाइल मौजूद नहीं है, तो आप फ़ाइल को खोलने का प्रयास करते हैं, और फिर कैच ब्लॉक में कुछ कोड जोड़ते हैं।

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

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

RecordIterator<MyObject> ri = createRecordIterator();
try {
   MyObject myobject = ri.next();
} catch(NoSuchElement exception) {
   // Object doesn't exist, will create it
}

यह बेहतर होगा:

RecordIterator<MyObject> ri = createRecordIterator();
if (ri.hasNext()) {
   // It exists! 
   MyObject myobject = ri.next();
} else {
   // Object doesn't exist, will create it
}

एंसर से जुड़ी टिप्पणी:

शायद मेरा उदाहरण बहुत अच्छा नहीं था - ri.next () को दूसरे उदाहरण में अपवाद नहीं फेंकना चाहिए, और यदि ऐसा होता है, तो वास्तव में कुछ असाधारण है और कुछ अन्य कार्रवाई कहीं और की जानी चाहिए। जब उदाहरण 1 का भारी उपयोग किया जाता है, तो डेवलपर्स विशिष्ट के बजाय एक सामान्य अपवाद को पकड़ लेंगे और मान लेंगे कि अपवाद उस त्रुटि के कारण है जिसकी वे अपेक्षा कर रहे हैं, लेकिन यह किसी और चीज़ के कारण हो सकता है। अंत में, यह वास्तविक अपवादों को नजरअंदाज करता है क्योंकि अपवाद अनुप्रयोग प्रवाह का हिस्सा बन गया है, और इसके अपवाद नहीं।

इस पर टिप्पणियाँ मेरे उत्तर से अधिक स्वयं को जोड़ सकती हैं।

Question 23

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

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

Question 24

मुझे लगता है, "इसे शायद ही कभी उपयोग करें" यह सही वाक्य नहीं है। मैं "केवल असाधारण स्थितियों में फेंकना" पसंद करूंगा।

कई लोगों ने समझाया कि सामान्य परिस्थितियों में अपवादों का उपयोग क्यों नहीं किया जाना चाहिए। अपवादों को त्रुटि से निपटने और विशुद्ध रूप से त्रुटि से निपटने के लिए उनका अधिकार है।

मैं एक अन्य बिंदु पर ध्यान केंद्रित करूंगा:

एक अन्य चीज प्रदर्शन का मुद्दा है। कंपाइलरों ने उन्हें जल्दी पाने के लिए लंबा संघर्ष किया। मुझे यकीन नहीं है, अब सटीक स्थिति कैसी है, लेकिन जब आप नियंत्रण प्रवाह के अपवादों का उपयोग करते हैं, तो इससे आपको एक और परेशानी होगी: आपका कार्यक्रम धीमा हो जाएगा!

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

तो आप बिना किसी जान-पहचान के अपने प्रोसेसर को जलाकर खत्म कर देंगे।

इसलिए: केवल असाधारण मामलों में अपवादों का उपयोग करें - अर्थ: जब वास्तविक त्रुटियां हुईं!

Question 25

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

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

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

Question 26

मैं अपवादों का उपयोग करता हूं यदि:

एक त्रुटि हुई जो स्थानीय और से बरामद नहीं की जा सकती है
यदि प्रोग्राम से त्रुटि बरामद नहीं हुई है, तो उसे समाप्त कर देना चाहिए।

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

यदि त्रुटि स्थानीय रूप से पुनर्प्राप्त नहीं की जा सकती है, लेकिन एप्लिकेशन जारी रह सकता है (उपयोगकर्ता ने एक फ़ाइल खोलने की कोशिश की लेकिन फ़ाइल मौजूद नहीं है) तो एक त्रुटि कोड उपयुक्त है।

यदि त्रुटि स्थानीय रूप से पुनर्प्राप्त नहीं की जा सकती है और एप्लिकेशन पुनर्प्राप्त किए बिना जारी नहीं रह सकता है (आप मेमोरी / डिस्क स्थान / आदि से बाहर हैं), तो एक अपवाद जाने का सही तरीका है।

Question 27

किसने कहा कि उन्हें रूढ़िवादी रूप से इस्तेमाल किया जाना चाहिए? प्रवाह नियंत्रण के लिए अपवादों का कभी भी उपयोग न करें और इसे ही सही। और अपवाद की लागत की परवाह कौन करता है जब यह पहले से ही फेंक दिया जाता है?

Question 28

मेरे दो सेंट:

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

मेरे लिए एक महान उदाहरण, फ़ाइल हैंडलिंग, या डेटाबेस हैंडलिंग है। मान लें कि सब कुछ ठीक है, और अंत में या कुछ अपवाद होने पर अपनी फ़ाइल बंद करें। या अपवाद होने पर अपने लेन-देन को रोलबैक करें।

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

जैसा कि पहले उल्लेख किया गया है, एक पारसेन्ट के लिए, मुझे अपवादों का विचार पसंद है। बस मान लौटाओ। यदि पैरामीटर पारगम्य नहीं था, तो एक अपवाद फेंक दें। यह एक ओर आपके कोड को क्लीनर बनाता है। कॉलिंग स्तर पर, आपको कुछ ऐसा करने की आवश्यकता है

try 
{
   b = ParseInt(some_read_string);
} 
catch (ParseIntException &e)
{
   // use some default value instead
   b = 0;
}

कोड साफ है। जब मुझे ParseInt मिलता है जैसे यह सब बिखरा हुआ है, तो मैं आवरण कार्य करता हूं जो अपवादों को संभालता है और मुझे डिफ़ॉल्ट मान लौटाता है। उदाहरण के लिए

int ParseIntWithDefault(String stringToConvert, int default_value=0)
{
   int result = default_value;
   try
   {
     result = ParseInt(stringToConvert);
   }
   catch (ParseIntException &e) {}

   return result;
}

इसलिए यह निष्कर्ष निकालने के लिए: मैंने जो चर्चा में चूक की, वह यह तथ्य था कि अपवाद मुझे अपने कोड को आसान / अधिक पठनीय बनाने की अनुमति देते हैं क्योंकि मैं त्रुटि स्थितियों को और अधिक अनदेखा कर सकता हूं। समस्या:

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

ताकि कभी-कभी एक अच्छा संतुलन खोजने में मुश्किल हो।

Question 29

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

बस प्रोग्रामिंग के हर नियम के बारे में वास्तव में एक दिशानिर्देश है, "यह मत करो" जब तक आपके पास वास्तव में अच्छा कारण नहीं है ":" कभी भी गोटो का उपयोग न करें "," वैश्विक चर से बचें "," नियमित अभिव्यक्तियाँ एक के बाद एक आपकी समस्याओं को बढ़ाती हैं। “, आदि अपवाद कोई अपवाद नहीं हैं…।