अपवाद कक्षाओं को डिजाइन करना

Question

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

मैंने कक्षा system_errorके एसटीएल कार्यान्वयन से प्रेरणा लेते हुए एक प्रकार के दृष्टिकोण का उपयोग करने का निर्णय लिया future_error।

मेरे पास एक त्रुटि है जिसमें त्रुटि कोड हैं:

enum class my_errc : int
{
    error_x = 100,
    error_z = 101,
    error_y = 102
};

और एक एकल अपवाद वर्ग (एक error_categoryप्रकार की संरचना और system_errorमॉडल द्वारा आवश्यक सब कुछ द्वारा समर्थित ):

// error category implementation
class my_error_category_impl : public std::error_category
{
    const char* name () const noexcept override
    {
        return "my_lib";
    }

    std::string  message (int ec) const override
    {
        std::string msg;
        switch (my_errc(ec))
        {
        case my_errc::error_x:
            msg = "Failed 1.";
            break;
        case my_errc::error_z:
            msg = "Failed 2.";
            break;
        case my_errc::error_y:
            msg = "Failed 3.";
            break;
        default:
            msg = "unknown.";
        }

        return msg;
    }

    std::error_condition default_error_condition (int ec) const noexcept override
    {
        return std::error_condition(ec, *this);
    }
};

// unique instance of the error category
struct my_category
{
    static const std::error_category& instance () noexcept
    {
        static my_error_category_impl category;
        return category;
    }
};

// overload for error code creation
inline std::error_code make_error_code (my_errc ec) noexcept
{
    return std::error_code(static_cast<int>(ec), my_category::instance());
}

// overload for error condition creation
inline std::error_condition make_error_condition (my_errc ec) noexcept
{
    return std::error_condition(static_cast<int>(ec), my_category::instance());
}

/**
 * Exception type thrown by the lib.
 */
class my_error : public virtual std::runtime_error
{
public:
    explicit my_error (my_errc ec) noexcept :
        std::runtime_error("my_namespace ")
        , internal_code(make_error_code(ec))
    { }

    const char* what () const noexcept override
    {
        return internal_code.message().c_str();
    }

    std::error_code code () const noexcept
    {
        return internal_code;
    }

private:
    std::error_code internal_code;
};

// specialization for error code enumerations
// must be done in the std namespace

    namespace std
    {
    template <>
    struct is_error_code_enum<my_errc> : public true_type { };
    }

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

ऊपर मेरे एक समीक्षक के साथ अच्छी तरह से नहीं बैठा। उनका विचार था कि मुझे एक अपवाद वर्ग के साथ एक अपवाद वर्ग की एक पदानुक्रम निर्मित करनी चाहिए थी std::runtime_errorक्योंकि इस स्थिति में एम्बेडेड त्रुटि कोड चीजों को मिलाता है - अपवाद और त्रुटि कोड - और यह एक बिंदु से निपटने के लिए अधिक थकाऊ होगा हैंडलिंग; अपवाद पदानुक्रम त्रुटि संदेश के आसान अनुकूलन के लिए भी अनुमति देगा।

मेरा एक तर्क यह था कि मैं इसे सरल रखना चाहता था, कि मेरी लाइब्रेरी को कई प्रकार के अपवादों को फेंकने की आवश्यकता नहीं थी और यह कि अनुकूलन इस मामले में भी आसान है क्योंकि इसे स्वचालित रूप से संभाला जाता है - इसका error_codeइससे error_categoryसंबद्ध अनुवाद है जो अनुवाद करता है उचित त्रुटि संदेश के लिए कोड।

मेरा कहना है कि मैंने अपनी पसंद, इस तथ्य के वसीयतनामे का अच्छी तरह से बचाव नहीं किया कि मुझे अभी भी C ++ अपवादों के बारे में कुछ गलतफहमी है।

मैं जानना चाहूंगा कि क्या मेरा डिजाइन समझ में आता है। मैंने जिस पद्धति को चुना है, उस पर अन्य पद्धति के क्या फायदे होंगे क्योंकि मुझे यह स्वीकार करना होगा कि मैं भी इसे देखने में असफल हूं? मैं क्या सुधार कर सकता था?

Comments

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

— मार्टिन यॉर्क

Answer 1

मुझे लगता है कि आपका सहयोगी सही था: आप अपने अपवाद मामलों को इस आधार पर डिज़ाइन कर रहे हैं कि ग्राहक कोड की अपवाद-हैंडलिंग आवश्यकताओं के आधार पर पदानुक्रम के भीतर इसे लागू करना कितना सरल है।

एक अपवाद प्रकार और त्रुटि स्थिति (आपके समाधान) के लिए गणना के साथ, यदि क्लाइंट कोड को एकल त्रुटि मामलों (उदाहरण के लिए my_errc::error_x) को संभालने की आवश्यकता होती है, तो उन्हें इस तरह कोड लिखना होगा:

try {
    your_library.exception_thowing_function();
} catch(const my_error& err) {
    switch(err.code()) { // this could also be an if
    case my_errc::error_x:
        // handle error here
        break;
    default:
        throw; // we are not interested in other errors
    }
}

कई अपवाद प्रकारों के साथ (संपूर्ण पदानुक्रम के लिए एक सामान्य आधार), आप लिख सकते हैं:

try {
    your_library.exception_thowing_function();
} catch(const my_error_x& err) {
    // handle error here
}

जहां अपवाद कक्षाएं इस तरह दिखती हैं:

// base class for all exceptions in your library
class my_error: public std::runtime_error { ... };

// error x: corresponding to my_errc::error_x condition in your code
class my_error_x: public my_error { ... };

पुस्तकालय लिखते समय, इसका उपयोग सरलता से होना चाहिए, आंतरिक कार्यान्वयन में आसानी (आवश्यक नहीं)।

आपको केवल उपयोग में आसानी से समझौता करना चाहिए (कैसे ग्राहक कोड जैसा दिखेगा) जब पुस्तकालय में इसे सही करने का प्रयास निषेधात्मक है।

Answer 2

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

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

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