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

Question

से फेंकने अपवाद मैं कंस्ट्रक्टर्स से अपवाद फेंकने के बारे में एक सह कार्यकर्ता के साथ एक बहस हो रही हैं और सोचा था कि मैं कुछ प्रतिक्रिया करना चाहते हैं।

यह देखने के एक डिजाइन बिंदु से, निर्माताओं से अपवाद फेंक करना ठीक है?

चलें कहते हैं कि मैं एक कक्षा में एक POSIX म्युटेक्स लपेटकर रहा हूँ, यह कुछ इस तरह दिखेगा:

class Mutex { 
public: 
    Mutex() { 
    if (pthread_mutex_init(&mutex_, 0) != 0) { 
     throw MutexInitException(); 
    } 
    } 

    ~Mutex() { 
    pthread_mutex_destroy(&mutex_); 
    } 

    void lock() { 
    if (pthread_mutex_lock(&mutex_) != 0) { 
     throw MutexLockException(); 
    } 
    } 

    void unlock() { 
    if (pthread_mutex_unlock(&mutex_) != 0) { 
     throw MutexUnlockException(); 
    } 
    } 

private: 
    pthread_mutex_t mutex_; 
}; 

मेरा प्रश्न है, इस यह करने के लिए मानक तरीका है? क्योंकि अगर pthread mutex_init कॉल विफल रहता है mutex ऑब्जेक्ट अनुपयोगी है तो अपवाद फेंकने से यह सुनिश्चित होता है कि mutex नहीं बनाया जाएगा।

क्या मुझे म्यूटेक्स कक्षा के लिए सदस्य फ़ंक्शन init बनाना चाहिए और pthread mutex_init को कॉल करना चाहिए जिसके भीतर pthread mutex_init की वापसी के आधार पर एक बूल वापस कर देगा? इस तरह मुझे निम्न स्तर की वस्तु के लिए अपवादों का उपयोग करने की आवश्यकता नहीं है।

Answer 1

हां, असफल कन्स्ट्रक्टर से अपवाद फेंकना यह करने का मानक तरीका है। अधिक जानकारी के लिए Handling a constructor that fails के बारे में इस FAQ को पढ़ें। एक init() विधि भी काम करेगी, लेकिन म्यूटेक्स के ऑब्जेक्ट को बनाने वाले सभी को याद रखना होगा कि init() को कॉल करना होगा। मुझे लगता है कि यह RAII सिद्धांत के खिलाफ चला जाता है।

Answer 2

हालांकि मैं सी ++ एक पेशेवर स्तर पर काम नहीं किया, मेरी राय में, यह ठीक कंस्ट्रक्टर्स से अपवाद फेंक है। मैं ऐसा करता हूं (यदि आवश्यक हो) .Net में। this और this लिंक देखें। यह आपकी रुचि का हो सकता है।

Answer 3

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

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

Answer 4

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

उदा।

func::func() : foo() 
{ 
    try {...} 
    catch (...) // will NOT catch exceptions thrown from foo constructor 
    { ... } 
} 

बनाम

func::func() 
    try : foo() {...} 
    catch (...) // will catch exceptions thrown from foo constructor 
    { ... } 

Answer 5

यह अपने निर्माता से फेंक करने के लिए ठीक है, लेकिन आप और सुनिश्चित करें कि मुख्य प्रारंभ होने के बाद अपने वस्तु का निर्माण किया है बनाना चाहिए इससे पहले कि यह खत्म:

class A 
{ 
public: 
    A() { 
    throw int(); 
    } 
}; 

A a;  // Implementation defined behaviour if exception is thrown (15.3/13) 

int main() 
{ 
    try 
    { 
    // Exception for 'a' not caught here. 
    } 
    catch (int) 
    { 
    } 
} 

Answer 6

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

Answer 7

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

class Scaler 
{ 
    public: 
     Scaler(double factor) 
     { 
      if (factor == 0) 
      { 
       _state = 0; 
      } 
      else 
      { 
       _state = 1; 
       _factor = factor; 
      } 
     } 

     double ScaleMe(double value) 
     { 
      if (!_state) 
       throw "Invalid object state."; 
      return value/_factor; 
     } 

     int IsValid() 
     { 
      return _status; 
     } 

    private: 
     double _factor; 
     int _state; 

} 

इस दृष्टिकोण के साथ समस्या कॉलर पक्ष पर है। वास्तव में ऑब्जेक्ट का उपयोग करने से पहले वर्ग के प्रत्येक उपयोगकर्ता को ऐसा करना होगा। यह बग के लिए एक कॉल है - जारी रखने से पहले एक शर्त का परीक्षण करने के लिए भूलने से कुछ भी आसान नहीं है।

कन्स्ट्रक्टर से अपवाद फेंकने के मामले में, ऑब्जेक्ट जो संरचना बनाता है उसे तुरंत समस्याओं का ख्याल रखना चाहिए। स्ट्रीम के नीचे ऑब्जेक्ट उपभोक्ता यह मानने के लिए स्वतंत्र हैं कि ऑब्जेक्ट केवल 100% परिचालन है जो उन्होंने प्राप्त किया है।

यह चर्चा कई दिशाओं में जारी रख सकती है।

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

class ScalerFactory 
{ 
    public: 
     Scaler CreateScaler(double factor) { ... } 
     int TryCreateScaler(double factor, Scaler **scaler) { ... }; 
} 

यह समाधान आपको यथा-स्थान स्थिति झंडा प्राप्त कर सकते हैं, कारखाने विधि की वापसी मान के रूप में साथ

, कभी बुरा डेटा के साथ निर्माता में प्रवेश के बिना ।

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

Answer 8

अलावा तथ्य यह है कि आप अपने विशिष्ट मामले में निर्माता से फेंक क्योंकि pthread_mutex_lock actually returns an EINVAL if your mutex has not been initialized और आप lock करने के लिए कॉल के बाद फेंक कर सकते हैं के रूप में std::mutex में किया जाता है की जरूरत नहीं है से:

void 
lock() 
{ 
    int __e = __gthread_mutex_lock(&_M_mutex); 

    // EINVAL, EAGAIN, EBUSY, EINVAL, EDEADLK(may) 
    if (__e) 
__throw_system_error(__e); 
} 

तो में कंस्ट्रक्टर्स से सामान्य फेंक ठीक निर्माण के दौरान अधिग्रहण त्रुटियों के लिए है, और आरए II (संसाधन-प्राप्ति-है-प्रारंभ) प्रोग्रामिंग प्रतिमान के अनुपालन में।

चेक इन बयानों पर इस example on RAII

void write_to_file (const std::string & message) { 
    // mutex to protect file access (shared across threads) 
    static std::mutex mutex; 

    // lock mutex before accessing file 
    std::lock_guard<std::mutex> lock(mutex); 

    // try to open file 
    std::ofstream file("example.txt"); 
    if (!file.is_open()) 
     throw std::runtime_error("unable to open file"); 

    // write message to file 
    file << message << std::endl; 

    // file will be closed 1st when leaving scope (regardless of exception) 
    // mutex will be unlocked 2nd (from lock destructor) when leaving 
    // scope (regardless of exception) 
} 

फोकस:

1. static std::mutex mutex
2. std::lock_guard<std::mutex> lock(mutex);
3. std::ofstream file("example.txt");

पहला कथन आरएआईआई और noexcept है।में (2) यह स्पष्ट है कि lock_guard पर RAII लागू किया गया है और यह वास्तव में throw कर सकता है, जबकि (3) ofstream में RAII नहीं लगता है, क्योंकि ऑब्जेक्ट्स को is_open() पर कॉल करके चेक किया जाना चाहिए जो failbit ध्वज को चेक करता है।

पहली नज़र में ऐसा लगता है कि यह ओ पी कार्यान्वयन के विपरीत यह मानक तरीका और पहले मामले std::mutex में प्रारंभ में फेंक नहीं है क्या पर दुविधा में पड़ा हुआ है, * *। दूसरे मामले में यह std::mutex::lock से जो भी फेंक दिया गया है उसे फेंक देगा, और तीसरे में कोई फेंक नहीं होगा।

सूचना मतभेद:

(1) स्थिर घोषित किया जा सकता है, और वास्तव में एक सदस्य चर (2) वास्तव में एक सदस्य चर के रूप में घोषित करने की कभी नहीं की उम्मीद होगी के रूप में घोषित किया जाएगा (3) है सदस्य चर के रूप में घोषित होने की उम्मीद है, और अंतर्निहित संसाधन हमेशा उपलब्ध नहीं हो सकता है।

ये सभी रूप RAII हैं; इसे हल करने के लिए, किसी को RAII का विश्लेषण करना होगा।

• संसाधन: अपनी वस्तु
• अधिग्रहण (आवंटन): यदि आप बनाया जा रहा वस्तु
• प्रारंभ: अपने ऑब्जेक्ट को उसके अपरिवर्तनीय राज्य में है

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

इसलिए, आपकी समस्या आपके शुरुआती राज्य को परिभाषित करने के लिए उबलती है। यदि आपके मामले में आपकी प्रारंभिक स्थिति है mutex को प्रारंभ किया जाना चाहिए तो आपको कन्स्ट्रक्टर से फेंकना चाहिए। इसके विपरीत यह ठीक है कि शुरूआत न करें (जैसा कि std::mutex में किया गया है), और म्यूटेक्स के रूप में आपके इनविरिएंट स्टेट को परिभाषित करें। किसी भी हाल में अपरिवर्तनीय उसके सदस्य वस्तु के राज्य द्वारा जरूरी compromized नहीं है, Mutex सार्वजनिक तरीकों Mutex::lock() और Mutex::unlock() के माध्यम से locked और unlocked के बीच mutex_ वस्तु mutates के बाद से।

class Mutex { 
private: 
    int e; 
    pthread_mutex_t mutex_; 

public: 
    Mutex(): e(0) { 
    e = pthread_mutex_init(&mutex_); 
    } 

    void lock() { 

    e = pthread_mutex_lock(&mutex_); 
    if(e == EINVAL) 
    { 
     throw MutexInitException(); 
    } 
    else (e) { 
     throw MutexLockException(); 
    } 
    } 

    // ... the rest of your class 
}; 

Answer 9

#include <iostream> 

class bar 
{ 
public: 
    bar() 
    { 
    std::cout << "bar() called" << std::endl; 
    } 

    ~bar() 
    { 
    std::cout << "~bar() called" << std::endl; 

    } 
}; 
class foo 
{ 
public: 
    foo() 
    : b(new bar()) 
    { 
    std::cout << "foo() called" << std::endl; 
    throw "throw something"; 
    } 

    ~foo() 
    { 
    delete b; 
    std::cout << "~foo() called" << std::endl; 
    } 

private: 
    bar *b; 
}; 


int main(void) 
{ 
    try { 
    std::cout << "heap: new foo" << std::endl; 
    foo *f = new foo(); 
    } catch (const char *e) { 
    std::cout << "heap exception: " << e << std::endl; 
    } 

    try { 
    std::cout << "stack: foo" << std::endl; 
    foo f; 
    } catch (const char *e) { 
    std::cout << "stack exception: " << e << std::endl; 
    } 

    return 0; 
} 

उत्पादन:

heap: new foo 
bar() called 
foo() called 
heap exception: throw something 
stack: foo 
bar() called 
foo() called 
stack exception: throw something 

विनाशकर्ता इसलिए यदि एक अपवाद एक निर्माता में फेंक दिया जाने की जरूरत है, कहा जाता है नहीं कर रहे हैं, सामान का एक बहुत (जैसे साफ?) करने के लिए ।