क्या बिना अपवाद के आरएआईआई करना संभव है?

Question

यदि कोई ऑब्जेक्ट किसी ऑब्जेक्ट के निर्माण में अधिग्रहण करने की आवश्यकता है तो असफल हो सकता है, यदि स्थानीय कोडिंग मानक द्वारा अपवादों को निषिद्ध किया जाता है तो क्या आरएआईआई करना संभव है?

यदि हां, तो इस मामले में संसाधन अधिग्रहण की विफलता को संभालने के लिए कैननिक तरीके क्या है?

Answer 1

मैं सामान्य रूप से अमान्य वस्तु दृष्टिकोण के साथ नहीं जाऊंगा क्योंकि मैं इसे खराब डिजाइन के रूप में मानता हूं। निर्माण के बाद, वस्तु एक ऐसे राज्य में होनी चाहिए जहां आविष्कार स्थापित किए जाएं (यही एकमात्र उद्देश्य है जिसे एक निर्माता को सेवा देना चाहिए)। पर std::vector जैसे कुछ को लागू करने पर विचार करें, लेकिन strange_vector<int>(10, 0) पर कॉल करने के बाद, ऑब्जेक्ट एक अनुपयोगी स्थिति में होगा क्योंकि आवंटन विफल रहा।

इसके बजाय मैं कंस्ट्रक्टर्स निजी घोषित करने और एक कारखाने तरीका है जिसके रिटर्न का प्रयोग करेंगे एक वैकल्पिक:

class file 
{ 
public: 
    ~file() {fclose(m_file);} 

    static std::optional<file> open(std::string const& filename) 
    { 
     auto f = fopen(filename.c_str(), "r"); 
     if (f) 
     { 
      return std::make_optional<file>(f); 
     } 
     else 
     { 
      return std::nullopt; 
     } 
    } 

private: 
    file(FILE* file); 
    FILE* m_file; 
}; 

अपवाद संचालन की सबसे बड़ी लाभों में से एक है (त्रुटि हैंडलिंग और सामान्य कोड पथ decoupling के अलावा) है कि आप नहीं कर सकते हैं उन्हें गलती से अनदेखा करें। यदि आप इसे चाहते हैं, तो आप अपनी खुद की कक्षा optional के समान बना सकते हैं, जब वैध ऑब्जेक्ट के साथ प्रारंभ नहीं किया गया है, तो एक त्रुटि संदेश लॉग करता है और आपके प्रोग्राम को समाप्त करता है (या कोई अन्य उचित त्रुटि प्रबंधन)। मुझे लगता है कि talk from A. Alexandrescu about systematic error handling है जहां वह कक्षा Expected<T> लागू करता है जिसमें T या अपवाद का मान शामिल है। आप इसका आधार उपयोग कर सकते हैं और अपवाद के बजाय वहां आपकी त्रुटि को संभालने में जोड़ें।

std::optional अभी तक मानक का हिस्सा नहीं है, लेकिन आप हाल ही में कंपाइलर्स, बूस्ट में, या अन्य पुस्तकालयों के हिस्से के रूप में आसानी से कार्यान्वयन प्राप्त कर सकते हैं।

Answer 2

आप हमेशा bool valid(void) विधि बना सकते हैं। कन्स्ट्रक्टर तब अप्रिय स्थिति निर्धारित कर सकता है और आपके कोड में, आप इस काम के बाद गीले निर्माण के बाद जांच सकते हैं या नहीं।

class foo 
{ 
public: 
    foo(const char *Filename) 
    { 
     mValid = false; 

     if(fopen(Filename) == NULL) 
      return; 

     mValid = true; 
    } 

    bool valid(void) { return mValid; } 

    private: 
     bool mValid; 
}; 

void myfunc(void) 
{ 
    foo fl("myfile"); 
    if(!fl.valid()) 
    { 
     printf("Error\n"); 
     return; 
    } 
}