अपवाद पदानुक्रम को संभालने के लिए विज़िटर पैटर्न

C ++ में अपवाद सबसे गंभीर भाषा तंत्रों में से एक हैं। विश्लेषण और त्रुटि से निपटने के लिए शक्तिशाली पर्याप्त क्षमताएं प्रदान करना। लेकिन अपवादों के साथ काम करना हमेशा इतना सुविधाजनक नहीं होता है।



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



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



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



पहली समस्या जिसका हमें सामना करना पड़ा, वह कोड दोहराव था। सबसे अच्छी स्थिति में, प्रत्येक प्लगइन में तीन बिंदु होते हैं जहां से अपवाद को फेंकने वाले कोड को बुलाया जा सकता है, और प्रत्येक ऐसे बिंदु की एक बड़ी पकड़ सूची होती है, जहां प्रत्येक प्रकार का अपवाद अपनी त्रुटि पाठ या कुछ अन्य प्रसंस्करण प्रदर्शित करता है। नए अपवादों को जोड़ने के साथ, यह और भी मजेदार हो जाता है, प्रोग्रामर को अपवादों को पकड़ने के कम से कम एक बिंदु को छोड़ देना चाहिए, और एक संभावित बग दिखाई देता है। बेशक, ऐसी स्थितियों को तुरंत इकाई या घटक परीक्षणों द्वारा कवर किया जाता है और जल्दी से पता लगाया जाता है, लेकिन जैसा कि वे कहते हैं: "एक त्रुटि का सबसे अच्छा सुधार इसकी घटना की संभावना को बाहर करना है।"



यह विचार है कि प्रत्येक मॉड्यूल के अपवादों में काम करने के लिए आगंतुक तंत्र के तरीकों के साथ अपना स्वयं का आधार वर्ग है:

namespace Exceptions { struct IBase : public std::exception { virtual void accept( IVisitor & _visitor ) const throw()= 0; }; } // namespace Exceptions
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

एक विज़िटर इंटरफ़ेस भी बनाया गया है जिसमें सभी प्रकार के मॉड्यूल अपवादों को "विज़िट" करने की विधियाँ घोषित की गई हैं:

 namespace Exceptions { struct IVisitor { virtual ~IVisitor() {} virtual void visit( CannotOpenFile const & _exception ) = 0; virtual void visit( NotHaveSpace const & _exception ) = 0; }; } // namespace Exceptions
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अपवादों का कार्यान्वयन कुछ इस तरह होगा:

 namespace Exceptions { class CannotOpenFile : public IBase { public: CannotOpenFile( std::string const & _filePath ) throw () : m_path( _filePath ) { } std::string const & getPath() const throw() { return m_path; } /*virtual*/ void accept( IVisitor & _visitor ) const throw() { _visitor.visit( *this ); } private: const std::string m_path; }; class NotHaveSpace : public IBase { public: /*virtual*/ void accept( IVisitor & _visitor ) const throw() { _visitor.visit( *this ); } }; } // namespace Exceptions
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

सभी प्रकार के अपवादों को पकड़ने के बजाय, केवल आधार प्रकार को पकड़ा जाता है, और इस तरह के अपवाद को संसाधित करने के लिए आवश्यक उद्देश्य के साथ एक आगंतुक का उपयोग किया जाता है:

 int main( int /*_argc*/, char * /*_argv[]*/ ) { int result = EXIT_SUCCESS; try { MyFile file; file.open( "file.my" ); } catch( Exceptions::IBase const & _exception ) { Exceptions::Visitors::Messenger visitor( std::cerr ); _exception.accept( visitor ); result = EXIT_FAILURE; } return result; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अपवाद :: आगंतुक :: मैसेंजर आगंतुक कुछ इस तरह दिखेगा:

 namespace Exceptions { namespace Visitors { class Messenger : public IVisitor { public: Messenger( std::ostream & _outputStream ) : m_outputStream( outputStream ) {} /*virtual*/ void visit( CannotOpenFile const & _exception ) { m_outputStream << "Cannot open file: " << _exception.getPath() << std::endl; } /*virtual*/ void visit( NotHaveSpace const & /*_exception*/ ) { m_outputStream << "Not have space for saving file" << std::endl; } private: std::ostream & m_outputStream; }; } // namespace Visitors } // namespace Exceptions
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

इस दृष्टिकोण का उपयोग कब करें

• परियोजना अपवादों की एक बड़ी पदानुक्रम का उपयोग करती है या केवल बड़ी संख्या में अपवाद हैं जो संक्षेप में लायक हो सकते हैं;
• एक ही पकड़ और अपवाद से निपटने के बिंदु एक से अधिक हैं।

सकारात्मक पक्ष

• आपको अधिक लचीले अपवाद हैंडलर लिखने की अनुमति देता है;
• आपको कई स्थानों पर एक हैंडलर का उपयोग करने की अनुमति देता है;
• वस्तुतः सभी स्थानों पर नए अपवादों से निपटने के लिए "भूल" करने की क्षमता को समाप्त कर देता है जहां आवश्यक हो।

नकारात्मक पक्ष

• अपवादों को संभालने के लिए हर बार (आगंतुक कक्षाएं) अतिरिक्त वस्तुओं का निर्माण;
• प्रत्येक असाधारण स्थिति के लिए एक अद्वितीय प्रकार का अपवाद होना चाहिए।

अंतभाषण

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