2012-02-20 11 views
9

मैं अन्य जावा ईई प्रोग्रामर अपने अपवाद हैंडलिंग के तरीके पर इनपुट इकट्ठा करने की कोशिश कर रहा हूं। क्या आप त्रुटि हैंडलिंग को केंद्रीकृत करते हैं (उदाहरण के लिए एक सर्वलेट फ़िल्टर)?जावा ईई परियोजनाओं के लिए अपवाद हैंडलिंग आर्किटेक्चर

क्या आप विभिन्न अनुप्रयोग परतों (दृढ़ता, सेवा, आदि) के लिए अलग-अलग अपवाद प्रकार बनाते हैं?

क्या आप अपवादों को निगलते हैं और उन्हें श्रृंखला को फेंक नहीं देते हैं?

अपवाद हैंडलिंग आर्किटेक्चर में अन्य पैराडाइम क्या हैं? आप किसका उपयोग करते हैं और क्यों?

उत्तर

7

दृढ़ता परत, यदि इसे जेपीए या हाइबरनेट का उपयोग करके लागू किया गया है, तो पहले से ही अपने अपवाद हैं, जो रनटाइम अपवाद हैं।

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

प्रेजेंटेशन लेयर का प्रत्येक नियंत्रक व्यावसायिक सेवाओं द्वारा फेंकने वाले चेक अपवादों के साथ सौदा करता है, जो एक सार्थक त्रुटि संदेश प्रदान करता है और उपयोगकर्ता को त्रुटि से पुनर्प्राप्त करने देता है (उदाहरण: फ़ॉर्म को दोबारा प्रदर्शित करें और उपयोगकर्ता से पूछें एक और नाम चुनने के लिए)

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

5

अपवाद शुद्ध सोने हैं जो आप गलत तरीके से पता लगाने की कोशिश कर रहे हैं। तदनुसार उनका इलाज करें!

निगलने के अपवाद केवल कुछ मामलों में स्वीकार्य है, जहां यह वास्तव में उचित कार्रवाई है।

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

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

ज्ञात मामलों के लिए, उचित कार्रवाई की जा सकती है।

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

1

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

संबंधित मुद्दे