किसी प्रोग्राम में अपवाद हैंडलिंग 24/7 चलाने की आवश्यकता है

Question

मैंने पढ़ा है कि हमें केवल उन अपवादों को पकड़ना चाहिए जिन्हें संभाला जा सकता है, जो आधार अपवाद वर्ग (इस मामले में C #) को एक बुरा विचार (अन्य कारणों के शीर्ष पर) को पकड़ने में सक्षम बनाता है। मैं वर्तमान में एक ऐसी परियोजना का हिस्सा हूं जिसमें मुझे अभी तक कुछ भी देखना बाकी है लेकिन आधार अपवाद को पकड़ा जा रहा है। मैंने उल्लेख किया कि ऐसा करने के लिए इसे बुरा अभ्यास माना जाता है, लेकिन प्रतिक्रिया थी "इस सेवा को 24/7 चलाने की आवश्यकता है, इसलिए यह तरीका है।"

चूँकि मेरे पास 24/7 चलाने की आवश्यकता वाले कार्यक्रम में अपवादों को ठीक से कैसे प्रबंधित करने के लिए एक अच्छी प्रतिक्रिया नहीं थी, इसलिए अब मैं यहां हूं। मैं "महत्वपूर्ण" कार्यक्रमों / सेवाओं में अपवाद से निपटने के तरीके पर कोई भी जानकारी / सुझाव खोजने में कामयाब नहीं हुआ हूं, जो घड़ी के चारों ओर चलने की आवश्यकता है (और इस मामले में मेरा मानना ​​है कि यह ठीक हो सकता है यदि सेवा एक मिनट के लिए नीचे है। या दो, तो भी महत्वपूर्ण नहीं है)। मैं समझता हूं कि यह कार्यक्रम की सटीक प्रकृति पर निर्भर करता है। ऑनलाइन गेम के लिए लॉग स्कैनर की तुलना में एक प्रोग्राम की आवश्यकताएं जो जीवन के लिए खतरा पैदा कर सकती हैं, काफी भिन्न हैं।

दो उदाहरण:

1: ब्रिटिश रेलवे के ग्राहकों के लिए एक टाइप-फॉरवर्ड सेवा, जिसका उपयोग वे रेलवे स्टेशनों के लिए ऑनलाइन खोज करते समय करते थे।

2: एक कार्यक्रम जो पटरियों, ट्रेनों आदि में विभिन्न सेंसर से प्रदान की गई वास्तविक समय की जानकारी के आधार पर उपरोक्त रेलवे के लिए रेलवे स्विच को स्वचालित रूप से नियंत्रित करता है।

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

Comments

वास्तविक समय ऐप (sic!) में अपवाद हैंडलिंग के दौरान स्टैक अनइंडिंग एक ट्रेन को बर्बाद कर सकता है।

— हिरण हंटर

@DeerHunter अपवादों के बिना खराब कोडिंग, एक ही परिणाम हो सकता है।

— B18овиЈ

ठीक है, तो आप catch Exception। इसका मतलब यह नहीं है कि आपका कार्यक्रम काम करता है , इसका मतलब है कि विफलताओं को एप्लिकेशन स्टेट को दूषित होने दिया जाता है जबकि यह निष्पादित करना जारी रखता है, जो कि एक बहुत अधिक खतरनाक जगह है। दुर्घटनाग्रस्त कार्यक्रम विनाशकारी हो सकता है, लेकिन एक ऐसा कार्यक्रम जो एक अमान्य स्थिति में है लेकिन फिर भी क्रिया करना सक्रिय रूप से विनाशकारी हो सकता है ।

— फशी

यदि एप्लिकेशन को 24/7 चलाने की आवश्यकता है, तो कहीं एक अनंत लूप है और इस अनंत लूप को कुछ निर्माण के चारों ओर लपेटा गया है जो सभी अखंडित अपवादों को पकड़ता है। यदि यह मामला नहीं है, तो एक अखंड अपवाद पहले से मौजूद कैच-सभी हैंडलर से अलग हो जाएगा, जो मुख्य और काबूम से बाहर है! 24/7 आवेदन समाप्त हो गया।

— डेविड हैमेन

Answer 1

कुछ खास भाषाएं जैसे

• कचरा इकठा करना
• अपवाद सिस्टम
• आलसी मूल्यांकन

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

---

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

इसे संक्षेप में प्रस्तुत करने के लिए: एक मजबूत कार्यक्रम में, विभिन्न भागों को एक दूसरे से अलग किया जाता है और स्वतंत्र रूप से फिर से शुरू या बढ़ाया जा सकता है।

तो मूल रूप से हमें इसके समकक्ष एक कोड की आवश्यकता है:

while (true) {
  try {
    DoWork();
  }
  catch (Exception e) {
    log(e);
  }
}

प्लस पाश को समाप्त करने का एक तरीका है। ऐसा लूप तब प्रत्येक वर्कर थ्रेड को चलाएगा।

---

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

बहुत सारे अपवादों को पकड़ने के साथ एक और समस्या यह है कि ऐसी सावधानी बरतने पर भी सभी अपवाद पुनः आरंभ करने से ठीक नहीं होते हैं। याददाश्त से बाहर निकलने जैसी कठिन समस्याओं को फिर से शुरू करके नियंत्रित किया जा सकता है। जब एक भौतिक केबल बाहर निकाला गया था, लेकिन इंटरनेट कनेक्टिविटी को फिर से प्राप्त करने में आपको पुनरारंभ करने में मदद नहीं करेगा।

Comments

हां, लेकिन "भौतिक केबल को बाहर निकाला गया" जैसी स्थिति ठीक वैसी ही है जब आप केवल अपवाद लॉग को भरना चाहते हैं जब तक कोई केबल को वापस नहीं डालता है, तब चीजें फिर से काम करना शुरू कर देती हैं, आवेदन के आगे मैनुअल रीस्टार्टिंग के साथ।

— मार्क हर्ड

Answer 2

आपके प्रश्न का उत्तर देने के लिए, किसी को यह समझना होगा कि अपवाद क्या हैं और वे कैसे काम करते हैं।

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

हैंडलर पकड़ने के बिना, कार्यक्रम निष्पादन को रोक देता है। आपके सेटअप और आवश्यकताओं के आधार पर, यह स्वीकार्य हो सकता है।

आपके विशिष्ट मामलों में:

1. यदि क्वेरी निष्पादित नहीं की जा सकती है (उदाहरण के लिए, गलत शहर का नाम), तो त्रुटि के उपयोगकर्ता को सूचित करें, और इसे ठीक करने के लिए कहें।
2. यदि आपको एक महत्वपूर्ण सेंसर से जानकारी नहीं मिल रही है, तो ऑपरेटर को समस्या को ठीक करने के लिए पूछे बिना जारी रखने में बहुत समझदारी नहीं है।

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

Answer 3

मुझे अभी तक कुछ भी देखना बाकी है लेकिन आधार अपवाद को पकड़ा जा रहा है।

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

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

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

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

Answer 4

बिंदु 2 के संबंध में: C # का उपयोग न करें। यह एक वास्तविक समय की भाषा नहीं है और अगर आप इसे इस तरह इस्तेमाल करने की कोशिश करेंगे तो आपको चोट लगेगी।

बिंदु 1 के लिए: आप एरलैंग तरीके से जा सकते हैं: इसे क्रैश होने दें, फिर पुनरारंभ करें

Comments

मेरा C # उपयोग और विशेषज्ञता बिंदु 2 (वास्तविक समय ट्रैक स्विचिंग) के आसपास नहीं है। मैं उत्सुक हूं कि ऐसे कार्य के लिए C # इतना अनुपयुक्त क्यों है?

— माइकल ओ'नील

ज्यादातर: कचरा कलेक्टर समय के संबंध में, अप्रत्याशित, कार्यक्रम व्यवहार करते हैं। इसके अलावा, रनटाइम बहुत जटिल है, और उन संदर्भों में आपको सरल चीजों की आवश्यकता है, वे अधिक अनुमानित हैं

— मिनीबिल

Answer 5

अस्वीकरण: ये केवल विचार हैं, मुझे अनुभव नहीं है।

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

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

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

एक उदाहरण एक ही मशीन पर दो प्रक्रियाएं हैं, जो एक दूसरे की निगरानी करती हैं और यदि एक को मार दिया जाता है, तो दूसरा इसे फिर से खोल देता है और इसे नष्ट कर देता है यह स्वयं से माता-पिता पीआईडी ​​है।