Windows अपवाद हैंडलिंग सुविधाएँ

हाल ही में पढ़ा गया विषय " डिबगिंग के लिए पकड़ - कोशिश का उपयोग करें " मैंने अभी भी एक अतिरिक्त के रूप में अपने अनुभव को साझा करने का फैसला किया।

इस लेख में, मैं विचार करने का प्रस्ताव करता हूं उस स्थान पर कॉलस्टैक प्राप्त करना जहां काम के मामले में एक अपवाद फेंक दिया गया था
संरचनात्मक अपवाद (एमएस विंडोज)। हम अपवादों के संचालन के विवरण में नहीं जाएंगे, क्योंकि यह लेखों की एक अलग श्रृंखला पर आकर्षित होता है (उन लोगों के लिए जो मेरी दिलचस्पी है, रिक्टर, MSDN और wasm.ru की सलाह देते हैं)। बेशक, मिनीडंप उत्पन्न करने के लिए कई तैयार परियोजनाएं हैं (उदाहरण के लिए क्रैश -प्ट या Google-ब्रेकपैड ), इसलिए यह लेख प्रकृति में अधिक शैक्षिक है।

प्राप्त कॉल स्टैक के साथ क्या करना है आप पर निर्भर है। आप इसे डिबगर के साथ देख सकते हैं, आप एक फ़ाइल पर लिख सकते हैं और इसे तीसरे पक्ष के कार्यक्रम के साथ देख सकते हैं (इसके लिए, अपने पते के साथ लोड किए गए मॉड्यूल की सूची लिखना न भूलें, साथ ही आपको डीबगिंग प्रतीकों की आवश्यकता होगी)।

सैद्धांतिक भाग

मैं तुरंत ध्यान देना चाहूंगा कि अपवाद निर्माणकर्ता में कॉल स्टैक प्राप्त करना सबसे अच्छा विकल्प नहीं है। सभी अपवाद आपके नहीं हैं, और हार्डवेयर अपवादों का एक वर्ग भी है, __try-__except try-catch निर्माण का उपयोग करके नहीं पकड़ा गया है, लेकिन __try-__except ।

हम एक पुनरावृत्त तरीके से समाधान पर जाएंगे ताकि यह स्पष्ट हो जाए कि यह कैसे काम करता है।

हार्डवेयर अपवाद के मामले में, सब कुछ सरल है। स्टैक स्पिन नहीं करता है, और हम अपवाद फ़िल्टर में कॉल स्टैक प्राप्त कर सकते हैं। एक प्रोग्राम अपवाद के मामले में, जब हम catch स्टैक पहले से ही अनवांटेड होता है, और अपवाद के कंस्ट्रक्टर में, हम स्टैक प्राप्त नहीं करने के लिए सहमत हुए। लेकिन यह पता चला है कि अगर try-catch __try-__except लपेटता है, तो, यहां तक ​​कि एक प्रोग्राम अपवाद के मामले में, हम पहले __except को __except गए फ़िल्टर पर __except । यहां हम कॉल स्टैक प्राप्त कर सकते हैं, लेकिन फ़िल्टर क्या चाहिए? यदि फ़िल्टर EXCEPTION_EXECUTE_HANDLER लौटाता है, तो हमें try-catch करने के लिए नहीं मिलेगा। खैर, EXCEPTION_CONTINUE_SEARCH लौटें, जो हैंडलर को अगले फ़िल्टर की तलाश करने के लिए प्रेरित करता है, जो EXCEPTION_EXECUTE_HANDLER देता है। इस मामले में, एक सॉफ़्टवेयर अपवाद के साथ, हम try-catch , और एक हार्डवेयर अपवाद के मामले में, अपवाद हैंडलिंग तंत्र स्टैक पर आगे हैंडलर देखने के लिए जाएगा, try-catch छोड़ देगा try-catch और इस तरह जब तक कि यह EXCEPTION_EXECUTE_HANDLER तर्क के साथ __except सामना नहीं करता है। ठीक है, फिर __try-__except(EXCEPTION_EXECUTE_HANDLER) में try-catch को __try-__except(EXCEPTION_EXECUTE_HANDLER) ।

वैसे, इस मामले में ब्लॉक

 __except(filter()/*-> EXCEPTION_CONTINUE_SEARCH*/) { /* */ } 

कभी सफल नहीं होते।

तो, हम स्केच करते हैं कि क्या हुआ (यह निर्माण संकलित नहीं करता है, क्योंकि आप एक ही फ़ंक्शन के अंदर अपवाद हैंडलिंग के विभिन्न रूपों का उपयोग नहीं कर सकते हैं):

 __try { try { __try { useful_unsafe_function(); } __except(filter()/*-> EXCEPTION_CONTINUE_SEARCH*/) { // this block will be never executed } } catch(const your_lib::Exception& ex) { } catch(const std::exception& ex) { } catch(...) { } } __except(EXCEPTION_EXECUTE_HANDLER) { } 

उपयोगी आवरण

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

लपेटें आवश्यकताएँ:

• सबसे सरल मामले में, किसी भी अपवाद को आवरण से परे नहीं बढ़ाया जाना चाहिए।
• एक प्रतिनिधि को स्वीकार करता है जो कुछ भी नहीं लौटाता है और तर्क स्वीकार नहीं करता है ( function<void()>
• हमारा मानना ​​है कि यदि कोई अपवाद होता है, तो रैपर को false रिपोर्ट करके यह रिपोर्ट देनी चाहिए।

यदि आपका तरीका एक वर्ग विधि है, और / या जो कुछ देता है और / या तर्क देता है, तो इन सभी निर्माणों को हमेशा एक प्रतिनिधि के रूप में दर्शाया जा सकता है जो कुछ भी वापस नहीं करता है और उसे तर्क की आवश्यकता नहीं होती है।

आवरण हाइलाइट्स:

हमारे आवरण का इंटरफ़ेस:

  struct SafeExecutor { typedef boost::function<void()> TDoDelegate; SafeExecutor(TDoDelegate doDelegate); // true - the everything is successful // false - otherwise bool Do(); private: bool DoCPlusPlusExceptionWrapper(); bool DoWorkWrapper(); private: TDoDelegate m_DoDelegate; }; 

कार्यान्वयन:

Filter फ़ंक्शन, जिसमें हमें कॉल स्टैक प्राप्त करना चाहिए, और जो EXCEPTION_CONTINUE_SEARCH लौटाता है:

  LONG Filter( PEXCEPTION_POINTERS pep ) { // pep->ExceptionRecord->ExceptionCode // pep->ExceptionRecord->ExceptionAddress // GetModules(); // GetCallStack(); return EXCEPTION_CONTINUE_SEARCH; } 

सबसे ऊपरी आवरण जो हार्डवेयर अपवादों के आगे प्रसार को रोकता है।

 bool SafeExecutor::Do() { bool AbnornalTermination = false; bool IsExecSuccessful = true; { __try { IsExecSuccessful = DoCPlusPlusExceptionWrapper(); } __except(EXCEPTION_EXECUTE_HANDLER) { AbnornalTermination = true; } } return !AbnornalTermination && IsExecSuccessful; } 

दूसरा आवरण - हम "सी ++ - अपवाद" को पकड़ते हैं और कार्यक्रम अपवादों के आगे वितरण को रोकते हैं।

 bool SafeExecutor::DoCPlusPlusExceptionWrapper() { bool res = true; try { res = DoWorkWrapper(); } catch(std::exception& /*ex*/) { // smth like log(ex.what()); //assert(false); res = false; } catch(...) { // smth like log("unknown sw-exception); //assert(false); res = false; } return res; } 

और तीसरा आवरण, जो कॉल प्रतिनिधि को पास किया गया है और Filter फ़ंक्शन, जिसमें हमें कॉल स्टैक प्राप्त करना होगा।

 bool SafeExecutor::DoWorkWrapper() { bool res = false; if (!m_DoDelegate.empty()) { __try { m_DoDelegate(); res = true; } __except(Filter(GetExceptionInformation())) // we must dump callstack inside this Filter { // never be executed because Filter always returns `CONTINUE_SEARCH` } } return res; } 

Google परीक्षण ढांचे पर मामलों का उपयोग करें।

हार्डवेयर अपवाद:

  int HWUnsafe() { int z = 0; return 1/z; } TEST(HWUnsafe, SafeExecutor) { SafeExecutorNS::SafeExecutor se(HWUnsafe); ASSERT_FALSE(se.Do()); } 

सॉफ्टवेयर अपवाद:

  int SWUnsafe1() { int z = 1; throw std::exception(); return 1/z; } TEST(SW_std_ex, SafeExecutor) { SafeExecutorNS::SafeExecutor se(SWUnsafe1); ASSERT_FALSE(se.Do()); } 

मैं ध्यान देता हूं कि प्रदर्शन के मामले में अपवाद संचालन एक महंगा ऑपरेशन हो सकता है, लेकिन डिबगिंग के लिए उपयोगी है।