यदि अपवाद पढ़ा जाना चाहिए।

अपवादों को डिज़ाइन करते समय क्या मुझे ऐसे संदेश लिखने चाहिए जो एक उपयोगकर्ता या एक डेवलपर को समझना चाहिए? वास्तव में अपवाद संदेशों का पाठक कौन होना चाहिए?

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

क्या संदेश लिखना बिल्कुल भी बेहतर नहीं होगा, बल्कि विशेष अपवाद रेंडरर्स हैं जो अलग-अलग भाषाओं में सार्थक संदेश बनाने की देखभाल करते हैं, बल्कि कोड में उन्हें हार्डकोड करते हैं?

मुझसे पूछा गया है कि क्या उनमें से कोई भी प्रश्न मेरे प्रश्न का उत्तर प्रदान करता है:

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

मुझे यह भी लगता है कि प्रसिद्ध संदेश का कोई वास्तविक मूल्य नहीं है क्योंकि यह केवल अपवाद प्रकार के नाम को अलग-अलग शब्दों में दोहराता है इसलिए उन्हें लिखने में परेशान क्यों करें? मैं उन्हें पूरी तरह से स्वचालित रूप से उत्पन्न कर सकता हूं।

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

जब मैं अन्य सभी लिंक किए गए प्रश्नों को पढ़ता हूं तो मुझे यह धारणा मिलती है कि एक अपवाद संदेश वास्तव में एक एंड-यूज़र द्वारा पढ़ा जा सकता है और डेवलपर नहीं ... एक संदेश एक केक के समान है और इसे भी खाएं।

design exceptions

— t3chb0t
स्रोत

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

— थॉमस ओवेन्स

@ThomasOwens मैंने उन दोनों को पढ़ा है, लेकिन वे अपवाद संदेश के विशिष्ट रिसीवर को संबोधित नहीं करते हैं। वे सामान्य रूप से उपयोगकर्ताओं के बारे में बात करते हैं लेकिन वह कौन है? क्या यह उस सॉफ़्टवेयर का उपयोगकर्ता है जिसे अब प्रोग्रामिंग या डेवलपर्स के बारे में विचार है जो गलत हो गया है, उसे एनालाइज करना चाहिए? मुझे यकीन नहीं है कि मुझे संदेश लिखते समय किससे पता करना चाहिए।

— t3chb0t

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

— मोनिका

क्यों पृथ्वी पर यह नकल के रूप में बंद था? यहां तक कि अगर यह उस दूसरे प्रश्न (जो यह नहीं है) का एक डुप्लिकेट था, तो यह स्पष्ट रूप से एक बेहतर उत्तर है, यह दूसरा होना चाहिए जिसे डुप्लिकेट के रूप में चिह्नित किया गया है।

— बेन आरोनसन

@MichaelT मैं अभी भी वास्तव में बहुत ओवरलैप नहीं देख रहा हूँ जब तक कि आप यह न मान लें कि अपवाद संदेश उपयोगकर्ताओं के लिए हैं

— बेन आरोनसन

जवाबों:

वे संदेश अन्य डेवलपर्स के लिए हैं

उन संदेशों को डेवलपर्स द्वारा एप्लिकेशन को डीबग करने में मदद करने के लिए पढ़ने की उम्मीद है । इसके दो रूप हो सकते हैं:

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

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

उदाहरण के लिए, IOSecurityExceptionकिसी फ़ाइल को लिखते समय एक अपवाद के प्रकार को समस्या के बारे में बहुत स्पष्ट नहीं है: क्या ऐसा इसलिए है क्योंकि हमारे पास फ़ाइल तक पहुंचने की अनुमति नहीं है? या शायद हम इसे पढ़ सकते हैं, लेकिन लिख नहीं सकते? या हो सकता है कि फ़ाइल मौजूद नहीं है और हमारे पास वहाँ फ़ाइल बनाने की अनुमति नहीं है? या शायद यह बंद है (उम्मीद है, अपवाद का प्रकार इस मामले में अलग होगा, लेकिन व्यवहार में, प्रकार कभी-कभी गूढ़ हो सकते हैं)। या शायद कोड एक्सेस सिक्योरिटी हमें किसी भी I / O ऑपरेशन को करने से रोकती है?

बजाय:

IOSecurityException: फ़ाइल मिल गई थी, लेकिन इसकी सामग्री को पढ़ने की अनुमति से इनकार कर दिया गया था।

बहुत अधिक स्पष्ट है। यहां, हम तुरंत जानते हैं कि निर्देशिका पर अनुमतियाँ सही तरीके से सेट की गई हैं (अन्यथा, हम यह नहीं जान पाएंगे कि फ़ाइल मौजूद है), लेकिन फ़ाइल स्तर पर अनुमतियाँ समस्याग्रस्त हैं।

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

ध्यान दें कि तकनीकी (अक्सर प्रदर्शन) कारणों के लिए, कुछ संदेश समाप्त होने की तुलना में बहुत अधिक गूढ़ होते हैं। .NET का NullReferenceException:

वस्तु का संदर्भ वस्तु की आवृत्ति अनुसार सेट नहीं। है।

एक संदेश का एक उत्कृष्ट उदाहरण है जो सहायक नहीं है। एक सहायक संदेश होगा:

ऑब्जेक्ट संदर्भ productको उस ऑब्जेक्ट के उदाहरण पर सेट नहीं किया जाता है जब उसे कॉल किया जाता है product.Price।

वे संदेश अंतिम उपयोगकर्ताओं के लिए नहीं हैं!

अंतिम उपयोगकर्ताओं को अपवाद संदेश देखने की उम्मीद नहीं है। कभी नहीँ। हालांकि कुछ डेवलपर्स उन संदेशों को उपयोगकर्ताओं को दिखाते हैं, इससे उपयोगकर्ता अनुभव और निराशा होती है। इस तरह के संदेश:

वस्तु का संदर्भ वस्तु की आवृत्ति अनुसार सेट नहीं। है।

अंत उपयोगकर्ता के लिए बिल्कुल कुछ भी नहीं है, और हर कीमत पर बचा जाना चाहिए।

सबसे खराब स्थिति यह है कि एक वैश्विक कोशिश / पकड़ है जो उपयोगकर्ता के अपवाद को फेंकता है और ऐप को बाहर निकालता है। एक आवेदन जो अपने उपयोगकर्ताओं की परवाह करता है:

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

आपके प्रश्न में, आपने एक अपवाद में दो संदेश देने का सुझाव दिया: डेवलपर्स के लिए एक तकनीकी, और अंतिम उपयोगकर्ताओं के लिए एक। हालांकि यह कुछ मामूली मामलों में एक मान्य सुझाव है, अधिकांश अपवाद एक स्तर पर निर्मित होते हैं जहां उपयोगकर्ताओं के लिए एक सार्थक संदेश का उत्पादन करना असंभव है। लो DivisionByZeroExceptionऔर कल्पना करो कि हम अपवाद को होने से नहीं रोक सकते और इसे स्वयं नहीं संभाल सकते। जब विभाजन होता है, तो क्या फ्रेमवर्क (क्योंकि यह फ्रेमवर्क है, न कि व्यवसाय कोड, जो अपवाद को फेंकता है) जानता है कि उपयोगकर्ता के लिए एक सहायक संदेश क्या होगा? बिलकुल नहीं:

शून्य से विभाजन हुआ। [ठीक है]

इसके बजाय, कोई इसे अपवाद को फेंकने दे सकता है, और फिर इसे एक उच्च स्तर पर पकड़ सकता है, जहां हम व्यापारिक संदर्भ जानते थे और वास्तव में अंतिम उपयोगकर्ता की मदद करने के लिए तदनुसार कार्य कर सकते थे, इस प्रकार कुछ दिखाते हैं:

फ़ील्ड D13 में फ़ील्ड E6 में एक के समान मान नहीं हो सकता है, क्योंकि उन मानों का घटाव एक भाजक के रूप में उपयोग किया जाता है। [ठीक है]

या हो सकता है:

एटीपी सेवा द्वारा सूचित मूल्य स्थानीय डेटा के साथ असंगत हैं। यह स्थानीय डेटा सिंक से बाहर होने के कारण हो सकता है। क्या आप शिपिंग जानकारी और पुनः प्रयास को सिंक्रनाइज़ करना चाहेंगे? [हाॅं नही]

वे संदेश पार्स करने के लिए नहीं हैं

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

अपवाद संदेश की कल्पना करें:

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

आप "500", "6", "4" और "377" मान निकालना चाहते हैं। उस दृष्टिकोण के बारे में थोड़ा सोचें जो आप पार्स करने के लिए उपयोग करेंगे, और उसके बाद ही पढ़ना जारी रखें।

आपके पास विचार है? महान।

अब, मूल डेवलपर ने एक टाइपो की खोज की:

Connecting to the caching sever timed out after waiting [...]

होना चाहिए:

                            ↓
Connecting to the caching server timed out after waiting [...]

इसके अलावा, डेवलपर का मानना है कि माह / सप्ताह / एक घंटा विशेष रूप से प्रासंगिक नहीं है, इसलिए वह एक अतिरिक्त परिवर्तन भी करता है:

कैशिंग सर्वर के लिए औसत प्रतीक्षा समय 6 एमएस था। पिछले महीने के लिए, 5 एमएस। पिछले 24 घंटों और 377 एमएस के लिए। आखिरी घंटे के लिए।

आपके पार्स करने से क्या होता है?

पार्स करने के बजाय, आप अपवाद गुणों का उपयोग कर सकते हैं (जिसमें डेटा को क्रमबद्ध किया जा सकता है, जैसे ही कोई भी चाहता है, उसमें शामिल हो सकते हैं):

{
    message: "Connecting to the caching [...]",
    properties: {
        "timeout": 500,
        "statistics": [
            { "timespan": 1, "unit": "month", "average-timeout": 6 },
            { "timespan": 7, "unit": "day", "average-timeout": 4 },
            { "timespan": 1, "unit": "hour", "average-timeout": 377 },
        ]
    }
}

अब इस डेटा का उपयोग करना कितना आसान है?

कभी-कभी (जैसे .NET के भीतर), संदेश को उपयोगकर्ता की भाषा में भी अनुवाद किया जा सकता है (IMHO, उन संदेशों का अनुवाद करना बिल्कुल गलत है, क्योंकि किसी भी डेवलपर को अंग्रेजी में पढ़ने में सक्षम होने की उम्मीद है)। ऐसे संदेशों को पार्स करना असंभव के करीब है।

— आर्सेनी मूरज़ेंको
स्रोत

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

— नील

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

— बजे आर्सेनी मूरज़ेंको

मुझे लगता है कि हर कोई जानता है कि "वस्तु संदर्भ ..." संदेश अप्रभावी है। प्रासंगिक सवाल हालांकि क्या मशीन कोड है जो आप उस संदेश को उत्पन्न करने के लिए घबराना पसंद करेंगे जो आप चाहते हैं? यदि आप इस अभ्यास को करते हैं तो आपको जल्दी पता चलता है कि सभी गैर-असाधारण मामलों पर लगाए गए भारी प्रदर्शन लागत के बिना संदेश आसानी से उत्पन्न नहीं किया जा सकता है । एक लापरवाह डेवलपर की नौकरी को बहुत आसान बनाने का लाभ अंतिम उपयोगकर्ता को प्रदर्शन हिट द्वारा भुगतान नहीं किया जाता है।

— एरिक लिपर्ट

सुरक्षा अपवादों के बारे में: अपवाद में कम जानकारी बेहतर है। मेरा पसंदीदा किस्सा यह है कि .NET 1.0 के एक पूर्व-बीटा संस्करण में आपको "C: \ foo.txt" फ़ाइल का नाम निर्धारित करने की अनुमति नहीं है, जैसे अपवाद संदेश मिल सकता है। महान, उस विस्तृत अपवाद संदेश के लिए धन्यवाद!

— एरिक लिपर्ट

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

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

इसका उत्तर पूरी तरह से अपवाद पर निर्भर करता है।

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

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

पकड़े गए अपवादों का मामला अधिक जटिल है, क्योंकि आपके पास अपवाद को ठीक से संसाधित करने और अधिक अनुकूल एक को फेंकने का अवसर है। एक स्क्रिप्टिंग भाषा मैंने लिखी थी, जिसका अपवाद एक डेवलपर के लिए बहुत स्पष्ट था। हालाँकि, स्टैक अनवाउंड के रूप में, मैंने स्क्रिप्टिंग भाषा के भीतर से उपयोगकर्ता-पठनीय स्टैक के निशान जोड़े। मेरे उपयोगकर्ता बहुत कम ही संदेश भेज सकते हैं, लेकिन वे अपनी स्क्रिप्ट में स्टैक ट्रेस को देख सकते हैं और पता लगा सकते हैं कि 95% समय क्या हुआ था। शेष 5% के लिए, जब उन्होंने मुझे फोन किया, तो हमारे पास न केवल एक स्टैक ट्रेस था, बल्कि एक डेवलपर-तैयार संदेश था जो मुझे यह पता लगाने में मदद करे कि क्या गलत था।

सभी में, मैं अपवाद संदेश को एक अज्ञात सामग्री के रूप में मानता हूं। आगे किसी और ने, जो कार्यान्वयन के बारे में अधिक जानता था, ने मेरे सॉफ़्टवेयर को अपवाद के रूप में सौंप दिया है। कभी-कभी मेरे पास एक कूबड़ होता है कि अज्ञात सामग्री अंतिम उपयोगकर्ता के लिए उपयोगी होगी, कभी-कभी यह नहीं है।

— कॉर्ट अमोन - मोनिका को बहाल करें
स्रोत

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

— Arseni Mourzenko

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

— Cort Ammon -

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

— कॉर्ट अमोन -