विंडोज़ सेवा में अपवाद का सर्वोत्तम अभ्यास संभालना?

Question

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

मैंने Scott Hanselman of exception handling best practice का आलेख पढ़ा है जहां वह लिखता है कि केवल कुछ मामले हैं जब आपको अपवाद निगलना चाहिए। मुझे लगता है कि किसी भी तरह से विंडोज सेवा कुछ मामलों में से एक है, लेकिन मुझे उस पर कुछ पुष्टि प्राप्त करने में खुशी होगी।

Answer 1

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

Answer 2

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

Answer 3

निगलने के अपवाद शायद ही कभी एक अच्छा विचार है और स्कॉट अपने लेख में कहता है, वास्तव में केवल कुछ वैध मामले हैं जहां यह सबसे अच्छा विकल्प हो सकता है।

मेरी सलाह सबसे पहले होगी, पता करें कि आप क्या अपवाद पकड़ रहे हैं और उन्हें पकड़ सकते हैं। भविष्य में यह आपके लिए अधिक उपयोगी होगा यदि आप जानते हैं कि जेनेरिक (Exception e)

एक बार जब आप ऊपर बताए गए अपवाद को पकड़ लेते हैं, तो उसे लॉगिंग सेवा में लिखना, शायद ईमेल करना कोड के रखरखाव के लिए विवरण या यहां तक ​​कि किसी अन्य ईवेंट को फायर करना जो कोड रखरखाव को एक नया संदेश जारी करने से पहले प्रयासों की संख्या पर सीमा के साथ कोड की पुन: प्रयास सेट करता है।

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

एक बार जब आप अपवादों के बारे में जानते हैं तो आपको पहले से अवगत नहीं था, फिर इन्हें अगली रिलीज में फिर से संभालने का एक और आदर्श तरीका माना जा सकता है।

Answer 4

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

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

Answer 5

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

एंटरप्राइज़ लाइब्रेरी का अपवाद हैंडलिंग ब्लॉक उपयोगी साबित हो सकता है क्योंकि आप कोड को बदलने के बिना कॉन्फ़िगरेशन के भीतर अपनी अपवाद नीति को संशोधित कर सकते हैं।

Answer 6

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

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

ऐसा लगता है कि आपका डिज़ाइन शेड्यूलर का उपयोग करने में सक्षम हो सकता है; बस विंडोज़ को "दिन में एक बार" भाग लेने दें और बस अपनी सेवा को एक ही समय में करें। अगर यह विफल रहता है, ठीक है; विंडोज अगले दिन इसे फिर से शुरू करने के लिए ज़िम्मेदार है।

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

बस कह रहा है: आप पुनर्विचार करना चाहते हैं कि आपको वास्तव में विश्वसनीयता बढ़ाने की आवश्यकता है (ध्यान में रखते हुए कि 100% विश्वसनीयता असंभव है; केवल घातीय लागत पर ही संपर्क किया जा सकता है)।

Answer 7

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