यह सुनिश्चित करना कि अपवाद हमेशा हैं? कुछ भी

कॉलिंग फ़ंक्शन द्वारा सी ++ में अपवादों को पकड़ा जाने की आवश्यकता नहीं है (कोई संकलन समय त्रुटियां नहीं)। तो यह डेवलपर के फैसले पर निर्भर है कि कोशिश / पकड़ (जावा के विपरीत) का उपयोग करके उन्हें पकड़ना है या नहीं।

क्या कोई तरीका यह सुनिश्चित कर सकता है कि कॉल किए गए अपवादों को हमेशा कॉलिंग फ़ंक्शन द्वारा प्रयास / पकड़ का उपयोग करके पकड़ा जाता है?

0
जोड़ा संपादित
विचारों: 2
अपवाद विनिर्देशों के लिए जावा के प्रसंस्करण दृष्टिकोण पर सर्वसम्मति यह है कि यह बुरी तरह टूटा हुआ है।
जोड़ा लेखक Pete Becker, स्रोत

7 उत्तर

नहीं।

कारणों के कारण अपवाद विनिर्देशों पर एक व्यावहारिक रूप देखें।

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

0
जोड़ा

आपके प्रश्न के दायरे के बाहर, इसलिए मैंने इसे पोस्ट करने पर बहस नहीं की लेकिन जावा में वास्तव में 2 प्रकार के अपवाद हैं, चेक किए गए हैं और अनचेक किए गए हैं। मूल अंतर यह है कि, c [++] की तरह, आपको एक अनचेक अपवाद पकड़ना नहीं है।

एक अच्छे संदर्भ के लिए इसे आज़माएं

0
जोड़ा

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

0
जोड़ा
यदि आपने इस अवधि के दौरान पढ़ा था, तो आपने देखा होगा कि मैंने स्पष्ट रूप से एक का उल्लेख किया है।
जोड़ा लेखक Ryan Fox, स्रोत
क्या, प्रार्थना, एक "महत्वपूर्ण" अपवाद है?
जोड़ा लेखक John Dibling, स्रोत

आपको यहां अपवाद का उपयोग नहीं करना चाहिए। यह स्पष्ट रूप से एक असाधारण मामला नहीं है यदि आपको हर जगह इसकी उम्मीद करने की आवश्यकता है तो आप इस समारोह का उपयोग करें!

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

class SearchResult
{
  private:
    ResultType result_;
    bool succeeded_;
    bool succeessChecked_;

  public:
    SearchResult(Result& result, bool succeeded)
      : result_(result)
      , succeeded_(succeeded)
      , successChecked_(false)
    {
    }

    ~SearchResult()
    {
      ASSERT(successChecked_);
    }

    ResultType& Result() { return result_; }
    bool Succeeded() { successChecked_ = true; return succeeded_; }
}
0
जोड़ा
जीसीसी में रिटर्न वैल्यू को संभालने की आवश्यकता के लिए कम से कम एक फ़ंक्शन विशेषता है। इस अतिरिक्त बूल से कम गन्दा।
जोड़ा लेखक Zan Lynx, स्रोत
@ जॉन डीबलिंग मुझे किसी ऐसे व्यक्ति को दिखाएं जो गंभीर है जो इसे नहीं कहता है।
जोड़ा लेखक James Kanze, स्रोत
इस वर्ग में एक कॉपी कन्स्ट्रक्टर और एक असाइनमेंट ऑपरेटर गुम है। कॉपी कन्स्ट्रक्टर बहुत महत्वपूर्ण है, क्योंकि मूल्य प्रतिलिपि द्वारा लौटाया जाता है (जिसे elided किया जा सकता है)। सी ++ 11 में, आप शायद प्रतिलिपि बनाने वाले की बजाय एक कोड कन्स्ट्रक्टर चाहते हैं, क्योंकि आप प्रतिलिपि बनाई जा रही वस्तु में सफलता जांच को रीसेट करना चाहते हैं।
जोड़ा लेखक James Kanze, स्रोत
मुझे किसी ऐसे व्यक्ति का उदाहरण दिखाएं जो क्वाक या हैक नहीं कह रहा है कि असाधारण स्थितियों के लिए अपवाद केवल हैं।
जोड़ा लेखक John Dibling, स्रोत
उस पर +1। यदि आप कुछ नतीजे की उम्मीद करते हैं, तो इसे अपवाद के रूप में वापस नहीं किया जाना चाहिए।
जोड़ा लेखक macbirdie, स्रोत
@ जॉन डीबलिंग मैंने इसे साथी जावा डेवलपर्स से बहुत कुछ सुना है, लेकिन मुझे अभी तक किसी भी पुस्तक, संदर्भ या उल्लेखनीय डेवलपर्स से उन सटीक शब्दों को सुनना / देखना नहीं है। यदि ऐसा है, तो पाइथन निर्माता को ज्ञापन नहीं मिला :)
जोड़ा लेखक Jason Mock, स्रोत

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

सी ++ 11 और आगे में, अब हमारे पास निर्दिष्टकर्ता निर्दिष्ट नहीं है
दोबारा, अगर हस्ताक्षर फेंकने के लिए चिह्नित किया गया है, तो अभी भी पुन: प्रयास नहीं किया जा रहा है कि इसे कॉलर द्वारा संभाला जा सकता है।


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

See: std::optional as part of the library fundamentals.

0
जोड़ा

क्या कोई तरीका यह सुनिश्चित कर सकता है कि   फेंकने वाले अपवाद हमेशा पकड़े जाते हैं   कॉलिंग द्वारा कोशिश / पकड़ का उपयोग कर   समारोह?

मुझे यह अजीब लगता है कि जावा भीड़ - स्वयं सहित - चेक अपवादों से बचने की कोशिश कर रहा है। वे RuntimeExceptions

0
जोड़ा

Chris' probably has the best pure answer to the question:

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

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

0
जोड़ा