अपवाद हैंडलिंग पैटर्न

Question

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

विकल्प हर अपवाद त्रुटि मामले के लिए एक वर्ग की घोषणा (हालांकि संबंधित अपवाद एक आम आधार वर्ग से derieve हैं) है- को

वहाँ एक मध्यम जमीन है लगता है? अनुशंसित विधि क्या है?

Answer 1

यह एक अच्छा सवाल है। मेरा मानना ​​है कि निश्चित रूप से एक मध्यम जमीन है।

क्यूए में त्रुटियों को प्रदर्शित करने के लिए मेरी राय में त्रुटि कोड आवश्यक हैं, और ग्राहकों के लिए ग्राहक सहायता और डेवलपर्स को वापस रिपोर्ट करने के लिए।

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

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

Answer 2

यदि आप अलग-अलग त्रुटि मामलों में व्यवहार को सामान्यीकृत कर सकते हैं, विशेष रूप से यदि इस तरह के व्यवहार को व्यवहार के "वर्ग" (कोई इरादा नहीं है) में वर्गीकृत किया जा सकता है, तो एक अपवाद वर्ग पदानुक्रम समझ में आता है।

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

Answer 3

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

Answer 4

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

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

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

अपवादों को संभालने के लिए कई पैटर्न हैं, इन तरह के सभी प्रकार के सवालों का जवाब देना। आम और उपयोगी पैटर्न का एक व्यापक संग्रह here पाया जा सकता है।