त्रुटि संदेश कितने विस्तृत होना चाहिए?

Question

मैं सोच रहा था कि त्रुटि संदेशों पर आम सहमति क्या थी। वे कितने विस्तृत होना चाहिए?

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

दूसरी तरफ मैं एक परियोजना जहां बहुत सामान्य त्रुटियों मिलता था पर काम किया है पर इस तरह के

के रूप में संकलन विफल कारण 3

कौन सा कहने की लगभग पूरी तरह से के रूप में बेकार था कारण 3 एक लिंक त्रुटि का मतलब बन गया।

तो मध्य जमीन कहां है? मुझे कैसे पता चलेगा कि मैंने वर्णनात्मक पर्याप्त त्रुटि संदेश जोड़े हैं? मुझे कैसे पता चलेगा कि उपयोगकर्ता यह समझने में सक्षम होगा कि वे कहां गलत हो गए हैं?

Answer 1

त्रुटि संदेश, उपयोगकर्ता और डेवलपर के लिए दो संभावित लक्षित ऑडियंस हैं।

आम तौर पर संदेश को उपयोगकर्ता को लक्षित करना चाहिए।

o समस्या का कारण क्या है।
ओ प्रोग्राम समस्या के आसपास क्यों काम नहीं कर सकता
ओ उपयोगकर्ता समस्या के आसपास काम करने के लिए क्या कर सकता है।
ओ समस्या की रिपोर्ट कैसे करें।

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

ओ मॉड्यूल का नाम
ओ समारोह नाम
ओ लाइन नंबर समस्या
ओ भी हो सकता है एक कोर डंप के सामान्य क्षेत्रों में ब्याज की
ओ चर।

सही दर्शकों को लक्षित करें।

Answer 2

आपको जो कुछ हुआ, उससे संवाद करना चाहिए, और उपयोगकर्ता के विकल्प क्या हैं, जितना संभव हो उतने शब्दों में। जितना लंबा त्रुटि संदेश है, उपयोगकर्ता इसे पढ़ने की संभावना कम है। एक ही टोकन द्वारा, लघु त्रुटि संदेश गुप्त और बेकार हैं। लंबाई के मामले में एक मीठा स्थान है, और यह हर स्थिति के लिए अलग है।

बहुत कम:

अमान्य इनपुट। इस तरह के 192.168.0.1 के रूप में

दर्ज करें सही रूप से फ़ॉर्मेट आईपी पता,:

बहुत लंबा है। एक आईपी पता एक नेटवर्क पर आपके कंप्यूटर की पहचान करने के लिए उपयोग किया जाता है।

सिर्फ सही:

कृपया कोई मान्य IP पता दर्ज करें।

जहां तक ​​कोड ब्लोट का संबंध है, यदि थोड़ा अतिरिक्त कोड उपयोगकर्ता को समर्थन कॉल करने या निराशाजनक होने से रोक देगा, तो यह एक अच्छा निवेश है।

Answer 3

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

मेरी राय में बहुत कम जानकारी होने से भी बदतर है।

यदि आप समृद्ध आत्मनिरीक्षण या अन्य क्षमताओं वाली भाषा का उपयोग कर रहे हैं, तो चेक में असफल होने वाली रेखा के साथ एक लॉग उपयोगी होगा। उपयोगकर्ता तब तकनीकी सहायता के लिए आगे बढ़ सकता है या अन्यथा विस्तृत जानकारी प्राप्त कर सकता है और यह अतिरिक्त कोड ब्लोट नहीं है, लेकिन जानकारी प्रदान करने के लिए अपने कोड का उपयोग कर रहा है।

Answer 4

दो प्रकार के त्रुटि संदेश हैं: जो उपयोगकर्ता द्वारा देखे जाएंगे और प्रोग्रामर द्वारा देखे जाएंगे।

"मुझे कैसे पता चलेगा कि उपयोगकर्ता यह समझने में सक्षम होगा कि वे कहां गलत हो गए हैं?" मुझे लगता है कि उन संदेशों को केवल उपयोगकर्ता द्वारा देखा जा रहा है, न कि बहुत तकनीकी, और COMPILE FAILED REASON 3 एक सामान्य अंत उपयोगकर्ता त्रुटि संदेश नहीं है। यह ऐसा कुछ है जो प्रोग्रामर देखेगा (उपयोगकर्ता आमतौर पर चीजों को संकलित नहीं करता है)।

तो, अगर यह उपयोगकर्ता है कि यह देखेंगे:

1. एक छोटी प्रदान करें ("ऑप्स कुछ गलत हो गया!", आदि) "यह एक त्रुटि संदेश है"
2. एक प्रदान करें त्रुटि का छोटा सामान्य विवरण ("जिस साइट से आप कनेक्ट करने का प्रयास कर रहे हैं वह अनुपलब्ध प्रतीत होता है"/"आपको XYZ कार्य करने के लिए पर्याप्त अनुमति नहीं है"/etc।
3. "विवरण जोड़ें >> "बटन, यदि आपका उपयोगकर्ता कंप्यूटर को अच्छी तरह समझने के लिए होता है, जिसमें विस्तृत जानकारी (अपवाद स्टैक ट्रेस, त्रुटि कोड इत्यादि)

अंत में, उपयोगकर्ता के लिए कुछ सरल और समझने योग्य आदेशों प्रदान ("पुनः प्रयास करें", "रद्द करें", आदि)

Answer 5

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

जब तक त्रुटि को सही करने का कोई तरीका है, तब उपयोगकर्ता को पर्याप्त जानकारी दें जो उन्हें स्वयं को सही करने की अनुमति देगी। अगर वे इसे स्वयं ठीक करने में सक्षम नहीं हैं तो क्या उन्हें दुर्घटना के तकनीकी कारण बताए जाने का कोई कारण है? बाद में समस्या निवारण के लिए फ़ाइल में लॉग इन करें।

Answer 6

के रूप में वे करने की आवश्यकता है विस्तृत रूप में;)

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

मैं लंबाई के बारे में जॉन बी की टिप्पणियों से भी सहमत हूं।

Answer 7

त्रुटि संदेशों का विस्तृत विवरण होना चाहिए, लेकिन स्पष्ट होना चाहिए। यह कई स्तरों से त्रुटि संदेशों को जोड़कर हासिल किया जा सकता है:

Failed to save the image 
Permission denied: /foo.jpg 

यहां हमारे पास दो स्तर हैं। और भी हो सकता है। सबसे पहले हम बड़ी तस्वीर बताते हैं और फिर हम विवरण बताते हैं। आदेश ऐसा है कि सबसे पहले हमारे पास सबसे अधिक भाग है और फिर भाग कम लोग समझते हैं, लेकिन दोनों अभी भी दिखाई दे सकते हैं।

इसके अतिरिक्त एक फिक्स सुझाव भी हो सकता है।