अपवाद वर्ग * निर्माता

Question

मैं VS2008

पर निम्न कोड में आए

if (!CreateProcess(NULL, 
        const_cast<LPWSTR>(ss.str().c_str()), 
        NULL, 
        NULL, 
        FALSE, 
        CREATE_NO_WINDOW|NORMAL_PRIORITY_CLASS, 
        NULL, 
        NULL, 
        &si, 
        &pi)) 
{ 
    throw std::exception("Unable to format Device"); 
} 

अब मैं MinGW जीसीसी के लिए कोड पोर्टिंग रहा हूँ और मैं त्रुटि

error: no matching function for call to 'std::exception::exception(const char [23])' 

मुद्दा मैं जांच प्राप्त

ध्यान दिया गया है कि विजुअल स्टूडियो में एक फ़ाइल अपवाद है जिसमें अपवाद वर्ग है और char * में लेता है। कुछ परिभाषाएं इस तरह की हैं

__CLR_OR_THIS_CALL exception(); 
    __CLR_OR_THIS_CALL exception(const char *const&); 
    __CLR_OR_THIS_CALL exception(const char *const&, int); 
    __CLR_OR_THIS_CALL exception(const exception&); 
    exception& __CLR_OR_THIS_CALL operator=(const exception&); 
    virtual __CLR_OR_THIS_CALL ~exception(); 
    virtual const char * __CLR_OR_THIS_CALL what() const; 

मेरा प्रश्न यह है कि मैं इस बिल्डिंग मुद्दे को mingw gcc पर कैसे रोकूं? क्या मुझे एक नई कक्षा बनाना चाहिए जो std :: runtime_error से विरासत में है और इसके बजाय इसे फेंक दें?

Answer 1

राय यहां एक भूमिका निभाती है। समस्या यह है कि std::exception में एक कन्स्ट्रक्टर नहीं है जो एक स्ट्रिंग तर्क लेता है; यह एक एमएसवीसी विस्तार है। मैं इसके बारे में जाने के लिए दो तरीके देखें:

1. एक स्ट्रिंग तर्क
2. std::exception

का प्रयोग न करें पहला मामला सीधा है पारित मत करो; बस

throw std::exception(); 

दोष यह है कि आपको एक वर्णनात्मक त्रुटि संदेश नहीं मिलता है।

यदि त्रुटि संदेश महत्वपूर्ण है, तो std::exception का उपयोग कर सीधे एक विकल्प नहीं है। इस मामले में, आप या तो std::logic_error या std::runtime_error, जो std::exception वारिस और एक स्ट्रिंग तर्क लेने कंस्ट्रक्टर्स है, इसलिए

throw std::runtime_error("Unable to format Device"); 

पहले से ही समस्या का समाधान हो सकता है इस्तेमाल कर सकते हैं। catch क्लॉज जो std::exception पकड़े गए हैं, वे std::runtime_error भी पकड़ लेंगे। एक संभावित समस्या है, हालांकि: catch क्लॉज जो std::runtime_error पकड़ते हैं std::exception नहीं पकड़ेगा लेकिन इसे पकड़ लेंगे।

यह एक कोने के मामले की तरह लगता है, और यह पूरी तरह से संभव है कि यह आपके लिए कोई समस्या नहीं है। यदि, हालांकि, संभावना है कि कॉल स्टैक के साथ catch क्लॉज है जो std::runtime_error पकड़ता है लेकिन इस कोड द्वारा निकाले गए अपवाद को नहीं पकड़ना चाहिए, तो आप std::exception से अपनी अपवाद कक्षा प्राप्त कर सकते हैं जो एक स्ट्रिंग तर्क लेता है। चूंकि कक्षा नई है, इसलिए यह मौजूदा catch क्लॉज द्वारा पकड़ा नहीं जाएगा। उदाहरण के लिए:

class descriptive_exception : public std::exception { 
public: 
    descriptive_exception(std::string const &message) : msg_(message) { } 
    virtual char const *what() const noexcept { return msg_.c_str(); } 

private: 
    std::string msg_; 
} 

और फिर

throw descriptive_exception("Unable to format Device"); 

यकीनन यह नहीं बहुत सुंदर है, और यह संभावना नहीं है कि यह आवश्यक है, इसलिए अधिक संभावित समाधान std::runtime_error या std::logic_error (या एक वर्ग का उपयोग करने के लिए है उनमें से एक से व्युत्पन्न)।

चाहे std::logic_error या std::runtime_error अधिक उपयुक्त है साफ़ नहीं है; इस मामले में मैं शायद std::runtime_error के साथ जाऊंगा क्योंकि त्रुटि सैद्धांतिक रूप से अनुमानित प्रतीत नहीं होती है, लेकिन std::domain_error और std::future_errorstd::logic_error से प्राप्त होता है, यह पूरी तरह से पदानुक्रम में जगह से बाहर नहीं होगा। यह, मुझे लगता है, राय का मामला है।