त्रुटि से निपटने में नियतिवाद

प्रस्तावना

यह लेख लेख की प्रतिक्रिया है: C ++ 2a में त्रुटि से निपटने के लिए क्या होगा । प्रत्येक पैराग्राफ के बाद, मुझे एक खुजली हुई, चंगा हुआ घाव खुल गया और खून बहने लगा। शायद मैं वही लिखूं जो मेरे दिल के बहुत करीब है। लेकिन मैं सिर्फ 21 वीं शताब्दी में C ++ प्रोग्रामर को दिखाने वाली कमियों और अशिक्षा के बारे में बात करना चाहता हूं। और शुरू में भी नहीं।

चलिए शुरू करते हैं।

वर्गीकरण

परंपरागत रूप से, कार्यक्रम की सभी गलत स्थितियों को 2 बड़े समूहों में विभाजित किया जा सकता है:

1. घातक त्रुटियाँ।
2. घातक या अपेक्षित त्रुटियाँ नहीं।

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

लेकिन ऐसा है, एक लगातार सूक्ष्म गलती।

आइए घातक त्रुटियों को देखें।

विभाजन 0 से । मुझे आश्चर्य है कि यह त्रुटि घातक क्यों है? मैं इस मामले में एक अपवाद फेंकना और इसे आगे की प्रक्रिया के लिए पकड़ना पसंद करूंगा। वह क्यों घातक है? मेरे खुद के कार्यक्रम का एक निश्चित व्यवहार मुझ पर क्यों लगाया गया है, और मैं इसे किसी भी तरह से प्रभावित नहीं कर सकता हूं? क्या C ++ लचीलेपन के बारे में नहीं है और इस तथ्य के बारे में कि भाषा प्रोग्रामर की ओर मुड़ी हुई है? हालांकि ...

नल पॉइंटर डेरेफ्रेंसिंग । मैं तुरंत जावा को याद करता हूं, एक NullPointerException जिसे संभाला जा सकता है। पोको लाइब्रेरी NullPointerException भी है! तो क्यों मानक डेवलपर्स बहरे-मूक के तप के साथ एक ही मंत्र दोहराते हैं?

आम तौर पर, मैंने इस विषय को क्यों शुरू किया? यह बहुत महत्वपूर्ण है और बस त्रुटि से निपटने के बारे में डेवलपर की समझ का पता चलता है। यह त्रुटि से निपटने के बारे में नहीं है, यह एक महत्वपूर्ण कार्रवाई के लिए एक प्रस्तावना है। यह हमेशा एप्लिकेशन की विश्वसनीयता के बारे में है, दोष सहिष्णुता के बारे में, और कभी-कभी, सबसे दुर्लभ और सबसे अधिक लुप्तप्राय में, मैं यहां तक ​​कहूंगा, प्रोग्राम के लुप्तप्राय प्रकार, व्यवहार और सुसंगत व्यवहार के बारे में।

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

आइए हम विभाजनवाद और उसकी अनुपस्थिति में विभाजन पर लौटते हैं ... मैं एक साधारण प्रश्न के साथ शुरू करूंगा: यदि मुझे नेटवर्क पर गलत डेटा मिला है, तो क्या यह एक घातक त्रुटि है?

सरल और सही उत्तर: पर निर्भर करता है। यह स्पष्ट है कि ज्यादातर मामलों में यह एक घातक त्रुटि नहीं है, और नेटवर्क पर प्राप्त सभी डेटा को मान्य किया जाना चाहिए और यदि डेटा गलत है तो 4xx लौटा दिए जाते हैं। क्या कोई ऐसे मामले हैं जब आपको दुर्घटना की आवश्यकता होती है? और जंगली हॉवेल के साथ दुर्घटनाग्रस्त हो गया, ताकि एसएमएस आए, उदाहरण के लिए। हाँ, और एक नहीं।

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

भाग्यवाद की पसंद

त्रुटि से निपटने में सबसे स्पष्ट बात यह तय है कि घातक क्या है और क्या नहीं है। लेकिन प्रत्येक प्रोग्रामर पूरे विकास गतिविधि के दौरान खुद से यह सवाल पूछता है। इसलिए, यह किसी तरह खुद को इस सवाल का जवाब देता है। सही जवाब किसी कारण से अभ्यास से आता है।

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

चुनौती । किसी चीज के लिए एक ढांचा बनाना।

सब कुछ सरल है। हम एक ढांचा बनाते हैं, उदाहरण के लिए, नेटवर्क इंटरैक्शन का। या JSON को पार्स करना। या, सबसे खराब, एक्सएमएल। सवाल तुरंत उठता है: लेकिन जब सॉकेट से कोई त्रुटि होती है - क्या यह एक घातक त्रुटि है या नहीं? विरोधाभास के लिए: क्या मुझे एक अपवाद फेंकना चाहिए, या एक त्रुटि वापस करनी चाहिए? यह एक असाधारण स्थिति है या नहीं? या std::optional लौटा सकते हैं? या एक नन? (1)

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

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

यदि हम किनारे पर जाते हैं, तो यह पता चलता है कि कभी-कभी यह समझना भी संभव नहीं है कि कौन किसका उपयोग करता है। यानी घटक A घटक B , और घटक B घटक A (^ 2) का उपयोग कर सकता है। यानी कौन निर्धारित करता है कि क्या होगा यह स्पष्ट नहीं है।

उलझन सुलझाना

जब आप इस सभी अपमान को देखते हैं, तो सवाल तुरंत उठता है: इसके साथ कैसे रहना है? क्या करें? अपने आप को चुनने के लिए क्या दिशानिर्देश हैं, ताकि विविधता में डूब न जाएं?

ऐसा करने के लिए, यह देखने और समझने के लिए उपयोगी है कि इस तरह के मुद्दों को अन्य स्थानों पर कैसे हल किया जाता है। हालांकि, किसी को समझदारी से खोजना होगा: संपूर्ण समाधानों से "स्टैम्प कलेक्शन" को अलग करना आवश्यक है।

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

त्रुटि से निपटने लक्ष्य नहीं है। जब भी हम त्रुटि से निपटने के बारे में बात करते हैं, हम तुरंत एक ठहराव पर आते हैं। क्योंकि यह एक लक्ष्य को प्राप्त करने का एक तरीका है। और प्रारंभिक लक्ष्य हमारे सॉफ्टवेयर को विश्वसनीय, सरल और समझने योग्य बनाना है। यह इन लक्ष्यों को निर्धारित किया जाना चाहिए और हमेशा पालन किया जाना चाहिए। और त्रुटि से निपटने बकवास है कि चर्चा के लायक नहीं है। मैं एक अपवाद फेंकना चाहता हूं - लेकिन स्वास्थ्य के लिए! एक गलती लौटा दी - अच्छा किया! एक मोनाद चाहते हैं? बधाई हो, आपने उन्नति का भ्रम पैदा किया, लेकिन केवल अपने ही सिर में (^ 4)।

तब मैं लिखना चाहता था कि यह कैसे करना है, लेकिन मैंने पहले ही लिखा था। घाव ठीक हो गए और खून बहना बंद हो गया। संक्षेप में, सुझाव हैं:

1. स्पष्ट सीमाओं के साथ घटकों में अलग।
2. सीमाओं पर, यह वर्णन करें कि यह क्या और कैसे उड़ सकता है। यह वांछनीय है कि यह एक समान हो। लेकिन बहुत अधिक महत्वपूर्ण है।
3. कोड में त्रुटियों को संभालना आसान होगा जो इसका उपयोग करेंगे।
4. यदि उपयोगकर्ता कोड लोड किए बिना कुछ आंतरिक रूप से संसाधित किया जा सकता है, तो इसे बाहर न रखें। उपयोगकर्ता को जितनी कम त्रुटियों को संभालना होगा, उतना ही बेहतर होगा।
5. अपने उपयोगकर्ता का सम्मान करें, गधे मत बनो! अपेक्षित व्यवहार के साथ सहज ज्ञान युक्त इंटरफेस लिखें ताकि उसे टिप्पणियों को पढ़ने और शपथ ग्रहण करने की आवश्यकता न हो।

5 वीं सलाह सबसे महत्वपूर्ण है, क्योंकि वह पहले चार को जोड़ती है।

PS बचपन में, मैं हमेशा एंथिल को देखने के लिए उत्सुक था। हजारों चींटियों, हर कोई कुछ करता है, अपने व्यवसाय के बारे में क्रॉल करता है। प्रक्रिया जारी है। अब मैं भी दिलचस्पी के साथ देख रहा हूं। एंथिल के पीछे भी। जहाँ हज़ारों व्यक्ति अपना छोटा सा काम कर रहे हैं। मैं उनके कठिन व्यवसाय में उन्हें शुभकामनाएं दे सकता हूं!

^ 1: लोग फैशनेबल चीजों के शौकीन हैं। जब सभी ने पर्याप्त खेला था, सी ++ प्रोग्रामर जाग गए, और फिर सब कुछ बदल गया।

^ 2: यह तब हो सकता है जब घटक बी में कई सार होते हैं जो उन्हें जोड़ता है। नियंत्रण का उलटा देखें।

^ 3: और अगले दिन, बेम, और स्क्रीन दुर्घटनाग्रस्त हो गई।

^ 4: मैं मोनाड्स के खिलाफ नहीं हूं, मैं महाप्राण के खिलाफ हूं, जैसे, देखो, यहां मोनाड है, अर्थात्। Endofunctors के monoidal श्रेणी में monoid! वाहवाही और अनुमोदन नोड्स को सुना जाता है। और कहीं दूर, दूर तक, बमुश्किल श्रव्य, किसी को संभोग।