कम से कम त्रुटि से निपटने के लिए एस्टर () मैक्रो एक्सटेंशन

"साहब, मैं एक ड्रैगन रक्षा के साथ आया था।" वह अब हमसे नहीं डरता है! यह एक ड्रैगन के पंखों के फड़फड़ाने से शुरू होता है और एक ज़ोर से सायरन बजाता है ताकि हर कोई ड्रैगन के पास आने की आवाज़ सुन सके।
"क्या यह रक्षा कुछ और करता है?"
"नहीं, क्यों?" हमें चेतावनी दी जाएगी!
"हाँ ... हॉवलिंग सायरन द्वारा खाया ... और फिर भी ... हमें याद दिलाएं जब हमने आउटेज की योजना बनाई है? ...

समस्या का वर्णन

यह विधि जटिल और जटिल परियोजनाओं में त्रुटि से निपटने की अवधारणा का ढोंग नहीं करती है। बल्कि, यह एक उदाहरण है कि न्यूनतम साधनों के साथ क्या किया जा सकता है।

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

इस तरह के विचार से मुखर () c / c ++ को परिष्कृत करने की आवश्यकता होती है। और अपने स्वयं के मैक्रोज़ को परिभाषित करें जो मानक मुखर () की कार्यक्षमता का विस्तार करते हैं - लेकिन न्यूनतम त्रुटि हैंडलिंग को जोड़कर। ऐसे मैक्रों को रहने दो।

VERIFY_EXIT (स्थिति);
VERIFY_RETURN (स्थिति, रिटर्नवैल्यू);
VERIFY_THROW (स्थिति, अपवाद);
VERIFY_DO (स्थिति) {/ * असफल ब्लॉक * /};

(इन मैक्रोज़ को अलग तरह से भी कहा जा सकता है। उदाहरण के लिए, VERIFY_OR_EXIT (), VERIFY_OR_RETURN (), VERIFY_OR_THROW (), VERIFY_OR_THROW ()। या छोटे संस्करण में इसके विपरीत।)

ये मैक्रोज़, सबसे पहले, संकलन के डिबग संस्करण और रिलीज़ संस्करण दोनों के लिए कार्यान्वयन है। यह उन्हें कार्यक्रम के रिलीज संस्करण में व्यवहार करने की अनुमति देता है। यानी न केवल परीक्षण के दौरान, बल्कि उपयोगकर्ता के साथ भी कार्रवाई करें।

मैक्रो विवरण

(मैक्रों का वर्णन अनुमानित है, उनका अन्य डिज़ाइन भी संभव है।)

1) VERIFY_EXIT (स्थिति);

यह स्थिति की स्थिति की जांच करता है और यदि यह गलत है, तो यह मानक मुखर () (डिबग संस्करण) को कॉल करता है, और वर्तमान फ़ंक्शन (डिबग और रिलीज़ संस्करण) को भी बाहर निकालता है।

2) VERIFY_RETURN (स्थिति, रिटर्नवैल्यू);

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

3) VERIFY_THROW (स्थिति, अपवाद);

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

4) VERIFY_DO (स्थिति) {/ * असफल ब्लॉक * /};

स्थिति की स्थिति की जाँच करता है और यदि यह गलत है, तो यह मानक मुखर () (डिबग संस्करण) को कॉल करता है, और मैक्रो (डीबग और रिलीज़ संस्करण) के तुरंत बाद विफल ब्लॉक या ऑपरेशन भी करता है।

सभी मैक्रोज़ के लिए यह महत्वपूर्ण है:

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

मैक्रो यूज पैटर्न

बेशक, सबसे दिलचस्प बात यह है कि एंट्रोपी सुपरमेन (कार्यक्रमों में त्रुटियों को कम करने के नायक) इन मैक्रोज़ का उपयोग कर रहे हैं।

1) पूर्व और बाद की स्थिति।

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

प्रस्तावित मैक्रोज़ का उपयोग सीधा है - हम प्रत्येक चेक को एक अलग मैक्रो में असाइन करते हैं। हम मैक्रो का चयन करते हैं कि हमें किस त्रुटि से निपटने की आवश्यकता है। (VERIFY_EXIT () - इस फ़ंक्शन से निकलने के साथ त्रुटि प्रसंस्करण, VERIFY_RETURN () - एक मूल्य की वापसी के साथ त्रुटि प्रसंस्करण, VERRIFY_THROW () - एक अपवाद के साथ त्रुटि प्रसंस्करण, आदि।

आप VERIFY () मैक्रो को भी जोड़ या उपयोग कर सकते हैं, जो किसी भी त्रुटि से निपटने नहीं करेगा। यह उपयोगी हो सकता है, उदाहरण के लिए किसी फ़ंक्शन के अंत में पोस्ट की स्थिति में।

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

2) लेन-देन का शब्दार्थ।

इसके अलावा, इन मैक्रों का उपयोग लेनदेन शब्दार्थ के साथ कोड को लागू करने के लिए किया जा सकता है। इस तरह के शब्दार्थ को समझा जाता है: 1) तैयारी के प्रत्येक चरण के परिणामों के सत्यापन के साथ एक ऑपरेशन के लिए क्रमिक तैयारी; 2) कार्रवाई का निष्पादन केवल अगर तैयारी के सभी चरणों सफल रहे थे; 3) पूरा करने से इनकार, अगर तैयारी की स्थिति में कुछ शर्तों को पूरा नहीं किया गया (कार्यान्वयन से एक संभावित रोलबैक के साथ)।

3) एक संभावित विस्तार को ध्यान में रखते हुए कोड को डिज़ाइन करना।

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

मैक्रो कार्यान्वयन

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

मैक्रों को एक कथन के रूप में प्रतिनिधित्व योग्य होना चाहिए। निर्माण (या इसी तरह) करते समय {} के साथ क्या किया जा सकता है। उदाहरण के लिए, इस तरह:

#define VERFY_EXIT(cond) \ do{bool _= (bool)(cond); assert(_); if(!_) {return;}} while(false) \ /*end macro VERIFY_EXIT()*/ 

फिर आप निम्नलिखित कोड लिख सकते हैं:

 if(a > 0) VERIFY_EXIT(a%2==0); 

बेशक, यह कार्यान्वयन की संभावनाओं में से केवल एक है। आप मैक्रोज़ को अन्य तरीकों से लागू कर सकते हैं।

पुनश्च सफल एंट्रोपी, सुपरमैन के साथ सफल लड़ाई!