जावा वेब अनुप्रयोग में अपवाद हैंडलिंग

Question

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

यदि आप मुझे उन परिदृश्यों में आपके लिए काम करने वाले ठोस समाधान प्रस्तुत करने वाले लेख/पुस्तकों के लिंक/नामों के बारे में बताते हैं तो मैं अत्यधिक सराहना करता हूं। समाधान कम से कम निम्नलिखित बिंदुओं को औचित्य के साथ साफ़ करना चाहिए:

1. जहां एसक्यूलेक्सप्शन पकड़े जाते हैं?
2. जहां अपवाद लॉग किए जाने चाहिए?
3. अनचेक अपवाद लॉग इन होना चाहिए?
4. प्रस्तुति परत पर अनचेक अपवाद पकड़े जाने चाहिए, और क्या उन्हें उपयोगकर्ता को दिखाया जाना चाहिए?
5. चेक अपवादों को कैसे प्रबंधित किया जाए, उनमें से कौन सा उपयोगकर्ता को दिखाया जाए और कैसे?
6. वैश्विक अपवाद हैंडलर पृष्ठ का उपयोग कैसे किया जाना चाहिए?
7. इस संदर्भ में ActionErrors को कैसे स्ट्रेट करना चाहिए?

धन्यवाद

Answer 1

1: जहां एसक्यूलेक्सप्शन पकड़े जाते हैं?

डेटा एक्सेस परत में डीएओ कक्षाओं में। यदि आवश्यक हो तो आप एक कस्टम डीएओ अपवाद के साथ लपेट सकते हैं। बदले में इस डीएओ अपवाद को अपवाद के रूप में आगे संभालना होगा।

2: जहां अपवाद लॉग किए जाने चाहिए?

इस समय जब आप throw पर हैं या मैसेजिंग फ्रेमवर्क से गुज़रने के लिए हैं।

3: अनचेक अपवाद लॉग किए जाने चाहिए?

उन्हें निश्चित रूप से लॉग इन होना चाहिए। उन्हें वास्तविक दुनिया में नहीं होना चाहिए, क्योंकि वे कोड तर्क (यानी डेवलपर गलती) में गलती का संकेत हैं जिन्हें बगफिक्स एएसएपी होना चाहिए। उन्हें कंटेनर तक सभी तरह से फेंक दिया जाना चाहिए और कंटेनर को <error-page>web.xml में उन्हें संभालने दें। उन्हें लॉग (और अंततः मेल) करने के लिए, Filter का उपयोग करें जो त्रुटि पृष्ठ पर सुनता है।

4: प्रस्तुति परत पर अनचेक अपवादों को पकड़ा जाना चाहिए, और क्या उन्हें उपयोगकर्ता को दिखाया जाना चाहिए?

वे बिल्कुल नहीं होना चाहिए।

5: अपवादों को कैसे प्रबंधित किया जाए, उनमें से कौन सा उपयोगकर्ता को दिखाया जाए और कैसे?

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

6: वैश्विक अपवाद हैंडलर पृष्ठ का उपयोग कैसे किया जाना चाहिए?

कम से कम उपयोगकर्ता के अनुकूल तरीके से। इस प्रकार, एक ही लेआउट में, कुछ प्रारंभिक "माफ करना" के साथ और यदि कुछ त्रुटि विवरण और एक ईमेल पता के साथ जरूरी है ताकि उपयोगकर्ता उस मामले के लिए संपर्क कर सके।

7: इस संदर्भ में ActionErrors को कैसे स्ट्रेट करना चाहिए?

उन्हें उपयोगकर्ता के लिए समान रूप में दिखाएं।

Answer 2

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

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

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

मुझे उम्मीद है कि घोषित किया जाएगा अपवाद के समान स्तर पर होने वाले अपवादों को इंटरफ़ेस/विधियों को परिभाषित करने के रूप में। जैसे TradeStore को TradeException फेंकने के लिए घोषित किया जाएगा, SQLException नहीं (क्योंकि व्यापार को संग्रहीत करने के तरीके TradeStore का कार्यान्वयन है - आप एक रिलेशनल डीबी, जावास्पेस इत्यादि में स्टोर कर सकते हैं)।

Answer 3

चेतावनी के रूप में, उपयोगकर्ताओं को निचले स्तर के त्रुटि संदेशों को प्रदर्शित करते समय, सुनिश्चित करें कि वे सिस्टम की जानकारी के लिए स्वच्छ हैं। यह एक ऐसा क्षेत्र है जहां कई सुरक्षा शोषण शुरू होते हैं। उन्हें पूरी जानकारी के साथ लॉग इन करें, लेकिन उपयोगकर्ता को केवल एक सामान्य त्रुटि संदेश प्रदर्शित करें।