2011-09-06 17 views
10

कुछ कोड पर विचार करें जो एक चेक अपवाद फेंक सकता है (प्रकार Exception का अपवाद)। आपका कोड catch बेशक अपवाद है। आप अपवाद को केवल निगल नहीं सकते हैं, आपका कोड उपयोगकर्ता को आपके उपयोगकर्ता इंटरफ़ेस के माध्यम से किसी भी तरह से रिपोर्ट करता है। एक लॉग फ़ाइल में, शायद, या एक जीयूआई पॉप-अप का उपयोग कर।क्या आपको अपवादों के संदेश पाठ की रिपोर्ट करनी चाहिए?

क्या आपके द्वारा उपयोगकर्ता को भेजे गए पाठ में अपवाद का संदेश टेक्स्ट शामिल होना चाहिए। यही है, Throwable.getMessage() या Throwable.getLocalizedMessage() द्वारा प्रदान किया गया पाठ?

मुझे नहीं लगता, लेकिन ऐसा लगता है कि मेरे साथ असहमत हैं। तो मुझे क्या गलत मिला है? मेरा तर्क इस प्रकार है।

  • संदेश तब बनाया गया जब अपवाद फेंक दिया गया था। इसलिए यह सर्वोत्तम रूप से बहुत कम स्तर की जानकारी प्रदान कर सकता है, जो किसी उपयोगकर्ता को रिपोर्ट करने के लिए अनुचित हो सकता है।
  • दार्शनिक रूप से, संदेश का उपयोग करके मुझे अपवादों के पूरे बिंदु के खिलाफ लगता है, जो हैंडलिंग और रिपोर्टिंग (catch भाग) पूरा होने से त्रुटि प्रबंधन (throw भाग) का पता लगाने और दीक्षा को अलग करना है। संदेश का उपयोग करना मतलब है कि संदेश रिपोर्टिंग के लिए अच्छा होना चाहिए, जो उस स्थान पर रिपोर्ट करने की ज़िम्मेदारी लेता है जो केवल पहचान और दीक्षा के लिए ज़िम्मेदार होना चाहिए। यही है, मैं तर्क दूंगा कि Throwable के डिजाइन का हिस्सा एक गलती थी।
  • संदेश स्थानीयकृत नहीं है। इसके नाम के बावजूद, getLocalizedMessage() बहुत अच्छा नहीं है क्योंकि आपको पता नहीं हो सकता कि आप catch अपवाद तक क्या लोकेल का उपयोग करना चाहते हैं (क्या आपके अंग्रेजी सिस्टम प्रशासकों द्वारा पढ़े गए सिस्टम लॉग पर जाने की रिपोर्ट है, या यह एक पॉप अप करने के लिए है जीयूआई के फ्रांसीसी उपयोगकर्ता के लिए खिड़की?)।
  • मुझे लगता है कि जावा 7 में IOException के लिए एक बेहतर अपवाद पदानुक्रम है, जिससे आप अलग-अलग catch खंडों में विभिन्न प्रकार के I/O erors को संभालने में सक्षम बनाते हैं, जिससे getMessage() टेक्स्ट कम महत्वपूर्ण होता है। इसका तात्पर्य है कि जावा डिजाइनर getMessage() के साथ कुछ हद तक असहज हैं।

मैं नहीं पूछ रहा हूँ कि क्या ढेर ट्रेस रिपोर्टिंग उपयोगी है। एक स्टैक-ट्रेस केवल एक अपवाद के लिए उपयोगी होने जा रहा है जो एक बग का सुझाव देता है। यह एक अनचेक अपवाद के लिए है। मुझे लगता है कि ऐसी परिस्थितियों में अपवाद संदेश का निम्न स्तर का विवरण प्रदान करना केवल उपयोगी नहीं है लेकिन अनिवार्य है। लेकिन मेरा प्रश्न चेक अपवादों से संबंधित है, जैसे फ़ाइल-नहीं मिला।

+0

एक संबंधित प्रश्न: http://stackoverflow.com/questions/2790528/extracting-user-friendly-exception-details-in-java – Raedwald

+0

कोई 1 आकार फिट नहीं है। यह इस पर निर्भर करता है कि "आपका लक्षित दर्शक कौन है?" – Pacerier

उत्तर

6

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

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

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

5

यदि आप उपयोगकर्ता को त्रुटि स्थिति पेश कर रहे हैं, तो यह शायद उपयोगकर्ता के अनुकूल संदेश होना चाहिए। अपवादों में तकनीकी विवरण होते हैं जिन्हें उपयोगकर्ता को जानने की आवश्यकता नहीं होती है।

कुछ स्थितियों में यह स्टैकट्रैक जानकारी प्रस्तुत करने के लिए एक सुरक्षा चिंता हो सकती है, इसलिए उपयोगकर्ता को कभी भी स्टैक निशान नहीं दिखाना चाहिए।

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

+1

एक स्टैक-ट्रेस केवल एक अपवाद के लिए उपयोगी होने जा रहा है जो एक बग का सुझाव देता है। यह एक अनचेक अपवाद के लिए है। मुझे लगता है कि अपवाद संदेश के निम्न स्तर के विवरण प्रदान करने वाली अपर्याप्त परिस्थितियां केवल उपयोगी नहीं बल्कि अनिवार्य है। लेकिन मेरा प्रश्न चेक अपवादों से संबंधित है, जैसे फ़ाइल-नहीं मिला। – Raedwald

+0

उस मामले में जहां आपको गंभीर बग के कारण अपवाद मिलता है, आपको उम्मीद है कि क्यूए ने इसका पता लगाया है। इसके बावजूद, यदि ऐप क्रैश हो जाता है, तो आप एक संदेश प्रदर्शित कर सकते हैं जो उपयोगकर्ताओं को पुन: उत्पन्न करने के लिए एक रिपोर्ट दर्ज करने के लिए कहता है। यदि आपके पास स्टैकट्रैक दिखाने के बजाय छुपा विवरण के आसपास कोई सुरक्षा आवश्यकता नहीं है .... – hvgotcodes

4

कुछ परियोजनाओं में, मैं एक विशेष प्रकार का अपवाद करता हूं (उदा। उपयोगकर्ताफ्रीडलीएक्सप्शन)। इस अपवाद प्रकार में उपयोगकर्ता के अनुकूल त्रुटि संदेश होना चाहिए।अगर मुझे ऐसा अपवाद मिलता है, तो मैं इसे उपयोगकर्ता को प्रदर्शित कर सकता हूं।

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

+2

वह अभी भी उस स्थान पर उपयोगकर्ता के अनुकूल संदेश बनाने की ज़िम्मेदारी रखता है, जो उस स्थान के बजाय 'अपवाद को फेंक देता है' इसे पकड़ो यह केवल 'getMessageMessage() 'के साथ' getMessage()' को प्रतिस्थापित करता है, जो लाभ का अधिक प्रतीत नहीं होता है। – Raedwald

0

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

+0

लॉग के पाठक भी आवेदन के उपयोगकर्ता हैं। – Raedwald

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

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