सिस्टम त्रुटियों से एक्सपेक्टेड हैंडलिंग (ईजीएस जावा, सी ++, पर्ल, पीएचपी में एक्सपोजर / टॉलरेटिंग / रिकवरिंग / डिज़ाइन करने के लिए एक डिज़ाइन पैटर्न / एप्रोच की सिफारिश करें)


13

क्या आप सिस्टम की त्रुटियों, एक्सेप्शन हैंडलिंग (जावा, C ++, पर्ल, पीएचपी) से एक्सपोजर / टॉलरेटिंग / रिकवरिंग / डिज़ाइन करने के लिए डिज़ाइन पैटर्न / एप्रोच की सिफारिश कर सकते हैं?

कुछ त्रुटियों को रिपोर्ट करने की आवश्यकता है।

कुछ त्रुटियों को आंतरिक रूप से नियंत्रित किया जा सकता है (एक पुनः प्रयास द्वारा या असंगत है (अनदेखा किया जा सकता है)।

आप उन्हें पकड़ने के लिए कोड की संरचना कैसे करते हैं?

लेकिन सभी त्रुटियों को लॉग इन करने की आवश्यकता है।

क्या सर्वोत्तम अभ्यास हैं?

और उन्हें अनुकरण करने के लिए उन घटकों को पूरी तरह से परीक्षण करने में सक्षम होने के लिए जो उनके द्वारा प्रभावित होते हैं?

सामान्य गैर-प्रोग्रामिंग-भाषा विशिष्ट प्रश्न कई आधुनिक प्रोग्रामिंग भाषाओं पर लागू होते हैं, लेकिन जावा, C ++, PHP और पर्ल में पैटर्न, दृष्टिकोण और दर्शन के उदाहरणों का स्वागत करेंगे।

(स्टैकओवरफ़्लो में भी पूछा गया: /programming/7432596/recommend-a-design-pattern-approach-to-exposing-tolerating-recovering-from-system लेकिन मैंने सोचा कि इसे प्रोग्रामर से भी पूछा जाना चाहिए क्योंकि मुझे लगता है कि प्रोग्रामर क्यू एंड ए व्यापक सॉफ्टवेयर / प्रोग्रामिंग मुद्दों को कवर करता है जबकि स्टैकओवरफ्लो तकनीकी कार्यान्वयन IMHO के बारे में अधिक है)।


2
मेरे लिए आपका प्रश्न बहुत अधिक सामान्य और खुला-सा लगता है जिसका प्रभावी ढंग से उत्तर दिया जा सकता है। इसे कुछ और विशिष्ट मामलों (विशेषों) और विशिष्ट एप्लिकेशन प्रकारों / वातावरणों (जैसे GUI ऐप / सर्वर / ...) तक सीमित रखने का प्रयास करें।
पेर्ट टॉर्क


@ Péter Török, mikera एक अच्छा जवाब प्रदान करता है, उनके स्वीकार करने की संभावना है।
इसके बाद

जवाबों:


16

विफल तेज़ एक बेहतरीन डिज़ाइन दृष्टिकोण है, और शायद इसे एक पैटर्न के रूप में गिना जा सकता है: http://en.wikipedia.org/wiki/Fail-fast

मुझे उपयोगी होने के लिए कई सिद्धांत भी मिले हैं:

  • प्रत्येक फ़ंक्शन / मॉड्यूल को इंटरफ़ेस के भाग के रूप में अपवादों पर विचार करें - अर्थात उन्हें दस्तावेज़ और जहां उपयुक्त / यदि आपकी भाषा इसका समर्थन करती है तो जाँच किए गए अपवादों का उपयोग करें।
  • असफलता को कभी न छोड़े - यदि यह विफल हो गया, तो आगे बढ़ने के लिए कुछ "प्रयास" करने की कोशिश जारी न रखें। उदाहरण के लिए, अशक्त मामलों के लिए विशेष हैंडलिंग अक्सर मेरे लिए एक कोड गंध है: यदि आपकी विधि को एक गैर-शून्य मान की आवश्यकता है, तो इसे तुरंत एक अपवाद फेंकना चाहिए अगर यह एक नल (या तो NullPointerException या आदर्श रूप से अधिक वर्णनात्मक IllegalArgumentException) का सामना करता है।
  • असाधारण मामलों के लिए और साथ ही सामान्य लोगों के लिए यूनिट परीक्षण लिखें - कभी-कभी ऐसे परीक्षण स्थापित करने के लिए मुश्किल हो सकते हैं लेकिन यह तब लायक है जब आप यह सुनिश्चित करना चाहते हैं कि आपका सिस्टम विफलताओं के लिए मजबूत है।
  • उस बिंदु पर लॉग ऑन करें जहां त्रुटि पकड़ी गई थी और संभाला गया था (यह मानते हुए कि त्रुटि को लॉग करने के लिए पर्याप्त गंभीरता थी)। इसका कारण यह है कि इसका मतलब है कि आप कारण को समझ गए थे और त्रुटि को संभालने के लिए एक दृष्टिकोण था, इसलिए आप लॉग संदेश को सार्थक कर सकते हैं .....
  • अपवादों का सही मायने में अप्रत्याशित परिस्थितियों / असफलताओं के लिए ही उपयोग करें। यदि आपका कार्य वास्तव में अपेक्षित तरीके से "विफल" होता है (उदाहरण के लिए यह देखने के लिए कि यदि अधिक इनपुट उपलब्ध है, और कोई भी नहीं मिल रहा है तो मतदान) तो उसे एक सामान्य प्रतिक्रिया ("कोई इनपुट उपलब्ध नहीं है") वापस करना चाहिए, अपवाद नहीं फेंकना चाहिए
  • असफल रूप से (स्टीवन लोवे के लिए श्रेय!) - यदि संभव हो तो, आमतौर पर अनजाने परिवर्तनों, रोलिंग लेन-देन या "अंत में" स्टेटमेंट या समतुल्य संसाधनों को मुक्त करके समाप्त करने से पहले सफाई करें। साफ-सफाई आदर्श रूप से उसी स्तर पर होनी चाहिए जिस पर संसाधन स्पष्टता और तार्किक स्थिरता के लिए प्रतिबद्ध थे।
  • यदि आपको विफल होना है, तो जोर से असफल हो - एक अपवाद जो आपके कोड का कोई भी हिस्सा नहीं संभाल पा रहा था (यानी बिना पकड़े + शीर्ष स्तर तक पहुंचाए) तत्काल, जोर से और दृश्य विफलता का कारण बन सकता है जो आपके ध्यान को निर्देशित करता है। मैं आमतौर पर कार्यक्रम या कार्य को रोक देता हूं और System.out को पूर्ण अपवाद रिपोर्ट लिखता हूं।

1
यह भी इनायत से विफल - यदि संभव हो तो समाप्त करने से पहले सफाई करें
स्टीवन ए। लोव

+1 @mikera क्या विचार करना है इसके बारे में स्पष्ट बिंदुओं के लिए। इसी तरह से स्वीकृत उत्तर, मैं दूसरों के योगदान के लिए थोड़ी देर के लिए खुला छोड़ दूंगा।
उपचार

+1 @Steve A. Lowe - उपयोगकर्ता-केंद्रित डिज़ाइन के लिए। जैसे फाइलों को सहेजना, टेंप फाइल्स को छोड़ना नहीं। मेरी प्रश्न सूची में संबंधित विषय के रूप में "डेटा स्वच्छता" के बारे में मेरा प्रश्न देखें।
इसके बाद

5

जावा और .NET में अपवादों के साथ काम करना और अपवादों को कैसे / कब / क्यों / कब पकड़ना है, इसके बारे में बहुत सारे लेख पढ़ने के बाद , मैं अंत में निम्नलिखित चरणों के साथ आया, जो मैं अपने सिर से गुजरता हूं जब भी मैं एक संभावित अपवाद देखता हूं, या एक अपवाद मुझे (जावा) पकड़ना चाहिए ... भले ही ऐसा कभी न हो (आह ...)। और यह काम करने लगता है, कम से कम मेरे लिए:

  1. क्या कुछ उपयोगी है जो मैं उस अपवाद के साथ कर सकता हूं, (लॉगिंग को छोड़कर)? यदि उत्तर हाँ है, तो वर्कअराउंड कोड लिखें, और यदि वर्कअराउंड अपवाद फेंक सकता है, तो 2 पर जाएं:
  2. अपवाद को रनटाइम अपवाद के आसपास लपेटें, इसे फेंकें, 3 पर जाएं।
  3. उच्च-स्तरीय वर्ग में जहां एक संभावित डेटाबेस / प्रक्रिया लेनदेन शुरू किया गया है, अपवाद को पकड़ें, लेन-देन को रोलबैक करें, अपवाद को हटा दें।
  4. शीर्ष स्तर के वर्ग में (जो लेनदेन शुरू किया गया हो सकता है), लॉगिंग ढाँचे का उपयोग करके अपवाद को लॉग करें जैसे कि slf4j ( उदाहरण के लिए log4j के साथ युग्मित ), या log4net । यदि संभव हो, तो सीधे वितरण सूची के अपवाद को ईमेल करें जो एप्लिकेशन के डेवलपर्स से बना है।
  5. यदि कोई GUI है, तो सबसे अधिक उपयोगकर्ता के अनुकूल तरीके से एक त्रुटि संदेश प्रदर्शित करें जो समस्या का कारण बना; अपवाद / स्टैकट्रेस प्रदर्शित न करें, उपयोगकर्ता परवाह नहीं करता है और यह जानने की आवश्यकता नहीं है कि यह NullPointerException थी।

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

लॉगिंग भाग को छोड़कर, मैं "मेरीरा" द्वारा लिखे गए बिंदुओं से पूरी तरह सहमत हूं; मैं सिर्फ इतना जोड़ूंगा कि अपवाद केवल एक बार लॉग इन होना चाहिए ।

इसके अलावा, मेरे द्वारा सूचीबद्ध कदम भिन्न हो सकते हैं यदि आप जो लिख रहे हैं वह एक एपीआई / फ्रेमवर्क है । वहाँ, अच्छी तरह से डिज़ाइन किए गए अपवादों को फेंकना डेवलपर्स को उनकी गलतियों को समझने में मदद करने के लिए अनिवार्य है।

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


Log4j के लिए +1 @Jalayn एक दृष्टिकोण के रूप में उल्लेख करता है, यह वही है जो मैं उपयोग करता हूं इसलिए यह किसी अन्य व्यक्ति को जानने के लिए इसे पुष्ट करता है।
उपचार

0

अपनी वस्तुओं का सही तरीके से निर्माण करें, बाहरी कारकों के बारे में चिंता न करें। यदि आप अपवादों का लाभ उठाना चुनते हैं, तो अपनी वस्तुओं को अपवादों में फेंक दें, यदि वे किसी चीज में विफल हो जाते हैं।

एक बार जब आपके सभी ऑब्जेक्ट सही तरीके से काम कर रहे हों, तो आपके डिज़ाइन में एक क्लीन एरर-हैंडलिंग जिम्मेदारी पदानुक्रम के साथ आना काफी आसान होना चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.