कई अपवाद संदेशों में उपयोगी विवरण क्यों नहीं हैं?

Question

ऐसा लगता है कि एक निश्चित मात्रा में समझौता है कि अपवाद संदेशों में उपयोगी विवरण होना चाहिए ।

ऐसा क्यों है कि सिस्टम घटकों के कई सामान्य अपवादों में उपयोगी विवरण नहीं हैं?

कुछ उदाहरण:

• नेट Listसूचकांक का उपयोग ArgumentOutOfRangeExceptionकरता है नहीं मुझे इंडेक्स मान की कोशिश की गई थी और अवैध था बताओ, और न ही यह मेरे अनुमत श्रेणी कहता है।
• मूल रूप से MSVC C ++ मानक पुस्तकालय से सभी अपवाद संदेश पूरी तरह से बेकार हैं (ऊपर के रूप में एक ही नस में)।
• .NET में Oracle अपवाद, आपको बता रहा है (paraphrased) "TABLE OR VIEW not found", लेकिन कौन सा नहीं ।

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

Comments

यह ध्यान दिया जाना चाहिए कि सुरक्षा पेशेवरों की ओर से, "त्रुटि संदेशों में सिस्टम के आंतरिक के बारे में कोई विवरण नहीं होना चाहिए" एक नियम है।

— तेलस्टिन

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

— मेसन व्हीलर

@ ग्राहक: यदि यह क्लाइंट-साइड सॉफ़्टवेयर है तो उपयोगकर्ता के लिए क्या दुर्गम है? मशीन का मालिक मशीन का मालिक होता है और वह किसी भी चीज को प्राप्त कर सकता है।

— मेसन व्हीलर

संबंधित पढ़ना: एक अच्छा अपवाद संदेश कैसे लिखें और घटिया त्रुटि संदेश के लिए उचित प्रतिक्रिया क्या है?

हमेशा कुछ अतिरिक्त जानकारी होती है जो आपके पास होती है। मुझे वे संदेश मिलते हैं जो आप उदाहरण देते हैं कि यह काफी अच्छा है। आप उनके साथ समस्या को डीबग कर सकते हैं। "त्रुटि 0x80001234" से बेहतर (उदाहरण विंडोज अपडेट से प्रेरित)।

— usr

Answer 1

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

हां, IndexOutOfRangeExceptionसटीक इंडेक्स होना चाहिए जो सीमा से बाहर था, साथ ही वह सीमा जो उस समय मान्य थी जो इसे फेंक दिया गया था, और यह .NET रनटाइम के रचनाकारों की ओर से अवमानना ​​है जो यह नहीं करता है। हां, ओरेकल के table or view not foundअपवाद में उस तालिका का नाम या दृश्य होना चाहिए जो नहीं मिला था, और फिर, यह तथ्य कि यह इसके लिए जिम्मेदार नहीं है, की ओर से अवमानना ​​है।

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

चूंकि लोग सोचते हैं कि अपवाद में मानव-पठनीय संदेश होना चाहिए, उनका मानना ​​है कि अपवाद द्वारा जो भी जानकारी ली जाती है, उसे भी मानव-पठनीय संदेश में स्वरूपित किया जाना चाहिए, और फिर वे सभी मानव-पठनीय संदेश लिखने के लिए ऊब गए हैं- बिल्डिंग कोड, या वे डरते हैं कि ऐसा करने से जो कुछ भी आंखें संदेश को देख सकती हैं, उन्हें जानकारी का एक अनजाना हिस्सा विभाजित किया जा सकता है। (अन्य उत्तरों द्वारा उल्लिखित सुरक्षा मुद्दे।)

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

इसलिए, प्रोग्रामर के लिए, अपवाद का "संदेश" अपवाद का वर्ग नाम है , और जो भी अन्य जानकारी अपवाद के अनुसार है , उसे अपवाद वस्तु के अंतिम (आसानी से / आसानी से) सदस्य चर में कॉपी किया जाना चाहिए। अधिमानतः, हर एक बोधगम्य थोड़ा सा। इस तरह, किसी भी संदेश को उत्पन्न (या करना) चाहिए, और इसलिए कोई भी prying आँखें इसे नहीं देख सकती हैं।

नीचे एक टिप्पणी में थॉमस ओवेन्स द्वारा व्यक्त चिंता को संबोधित करने के लिए:

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

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

पुनश्च

इस विषय पर मेरे कुछ और विचार इस उत्तर में मिल सकते हैं: एक अच्छा अपवाद संदेश कैसे लिखें

पी पी एस

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

Comments

मैंने .NET फ्रेमवर्क में कुछ अपवाद वर्गों को देखा है, और यह पता चला है कि इस तरह की जानकारी को प्रोग्रामेटिक रूप से जोड़ने के लिए बहुत सारे अवसर हैं। इसलिए मुझे लगता है कि सवाल "क्यों नहीं?" लेकिन पूरी "मानव-पठनीय" चीज़ के लिए +1।

— रॉबर्ट हार्वे

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

— थॉमस ओवेन्स

तो प्रोग्रामर मानव नहीं हैं? मेरे सहयोगियों को देखते हुए यह कुछ संदेह की पुष्टि करता है जो मैंने कुछ समय के लिए किया है ...

— gbjbaanb

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

— मेसन व्हीलर

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

— माइकल हैम्पटन

Answer 2

ऐसा क्यों है कि सिस्टम घटकों के कई सामान्य अपवादों में उपयोगी विवरण नहीं हैं?

मेरे अनुभव में, कई कारण हैं जिनमें अपवादों में उपयोगी जानकारी नहीं है। मुझे उम्मीद है कि इस तरह के कारण सिस्टम घटकों पर भी लागू होंगे - लेकिन मुझे यकीन नहीं है।

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

क्या मेरी उम्मीदें रेखा से बाहर हैं? क्या मैं अपवादों का गलत उपयोग कर रहा हूं कि मुझे यह भी पता है?

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

Comments

मुझे पता है कि इसे C के रूप में चिह्नित किया गया है, लेकिन मुझे यह जोड़ना चाहिए कि आपका अंतिम पैराग्राफ सभी भाषाओं पर लागू नहीं होता है क्योंकि कुछ (सही या गलत तरीके से) अपवाद-आधारित त्रुटि से निपटने और रिपोर्टिंग पर बहुत भरोसा करते हैं ।

— लिलिएनथल

@ लिलिंथल - जैसे? मैं जिस भाषा से बहुत परिचित हूं, वह नियमित रूप से उस तरह की बात नहीं करती है।

— तेलस्टिन

मुझे लगता है कि इस उत्तर में बहुत अच्छी सामग्री है, लेकिन यह नीचे की रेखा को कहने से बचता है, जो कि "उन्हें चाहिए।"

— djechlin

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

— मार्टिन बा

@Telastyn SAP के मालिकाना ABAP में एक अपवाद वर्ग निर्माण एक संदेश हो सकता है, जो मूल रूप से एक गतिशील (बहुभाषी) संदेश के साथ उपयोगकर्ता को कार्यक्रम की स्थिति (सफलता, विफलता, चेतावनी) को रिपोर्ट करने के लिए है। मैं मानता हूँ कि मैं नहीं जानता कि इस तरह की बात कितनी व्यापक है, या यदि इसे भाषाओं में प्रोत्साहित किया जाता है तो यह संभव है लेकिन कम से कम एक ऐसा है जहाँ यह (अफसोस की बात है) आम बात है।

— लिलियनथल

Answer 3

मेरे पास विशेष रूप से सी # अनुभव, या सी ++ की अधिकता नहीं है, लेकिन मैं आपको यह बता सकता हूं - डेवलपर-लिखित अपवाद 10 में से 9 बार किसी भी सामान्य अपवाद की तुलना में अधिक उपयोगी हैं जो आप कभी भी पाएंगे, अवधि।

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

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

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

यह हमेशा आपकी मदद नहीं करेगा - क्योंकि आप हमेशा यह अनुमान नहीं लगा सकते कि त्रुटि संदेश क्या उपयोगी होगा - लेकिन यह लंबे समय में आपके अपने आवेदन को बेहतर ढंग से समझने का पहला कदम है।

Answer 4

सवाल विशेष रूप से पूछ रहा है कि "सिस्टम घटकों" (उर्फ मानक पुस्तकालय कक्षाओं) द्वारा फेंके गए कई अपवादों में उपयोगी विवरण क्यों नहीं हैं।

दुर्भाग्य से, अधिकांश डेवलपर्स मानक पुस्तकालयों में मुख्य घटक नहीं लिखते हैं, और न ही विस्तृत डिज़ाइन दस्तावेज़ या अन्य डिज़ाइन तर्क आवश्यक रूप से सार्वजनिक किए गए हैं। दूसरे शब्दों में, हम निश्चित रूप से कभी नहीं जान सकते हैं।

हालांकि, इस बात का ध्यान रखने के लिए दो प्रमुख बिंदु हैं कि विस्तृत अपवाद जानकारी वांछनीय या महत्वपूर्ण क्यों नहीं हो सकती है:

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

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

Comments

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

— बेन आरोनसन

@BenAaronson अपवाद की पहचान / वर्ग हमें त्रुटि का प्रकार बताता है। मेरी बात यह है कि विवरण को छोड़ा जा सकता है (यानी विशिष्ट मूल्य त्रुटि के कारण क्या है)। एक हमलावर के लिए जानकारी का खुलासा करते हुए, वह मूल्य उपयोगकर्ता इनपुट पर वापस प्राप्त करने योग्य हो सकता है।

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

— gbjbaanb

@gbjbaanb जो कहता है कि हमें उपयोगकर्ता को पूर्ण स्टैक ट्रेस दिखाने की आवश्यकता है?

उस अंतर्दृष्टि को साझा करने के लिए धन्यवाद। व्यक्तिगत रूप से, मैं सहमत नहीं हूं और लगता है कि सुरक्षा तर्क एक पूर्ण गिरावट है, लेकिन यह एक तर्क हो सकता है।

— मार्टिन बा

Answer 5

सबसे पहले, मुझे यह कहते हुए एक बुलबुला फोड़ना चाहिए कि भले ही डायग संदेश 4 सेकंड में सटीक कोड लाइन और सब कमांड में लाने वाली जानकारी से भरा हो, संभावना है कि उपयोगकर्ता इसे कभी नहीं लिखेंगे या इसे समर्थन लोगों तक पहुंचाएंगे। और आपको बताया जाएगा "वैसे इसने उल्लंघन के बारे में कुछ कहा है ... मुझे नहीं पता कि यह जटिल लग रहा था!"

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

हाल ही में एक आवेदन के पुनर्निर्माण में, एक निर्णय किया गया था कि रिटर्न कोड तीन समूहों में से एक में गिरेंगे:

• 0 के माध्यम से 9 अतिरिक्त जानकारी के साथ सफलता के माध्यम से सफल होगा।
• 10 के माध्यम से 99 गैर-घातक (पुनर्प्राप्त करने योग्य) त्रुटियां होंगी, और
• 255 के माध्यम से 101 घातक त्रुटियां होंगी।

(100 किसी कारण से छोड़ दिया गया था)

किसी भी विशेष वर्कफ़्लो में, हमारे विचार का पुन: उपयोग किया गया या सामान्य कोड में घातक त्रुटियों के लिए सामान्य रिटर्न (> 199) का उपयोग किया जाएगा, जिससे हमें काम के प्रवाह के लिए 100 घातक त्रुटियां संभव हैं। संदेश में थोड़ा अंतर करने वाले डेटा के साथ, फ़ाइल जैसी त्रुटियां नहीं मिलीं, सभी समान कोड का उपयोग कर सकते हैं और संदेशों के साथ अंतर कर सकते हैं।

जब कोड ठेकेदारों से वापस आता है, तो आप हमारे आश्चर्य पर विश्वास नहीं करेंगे, जब लगभग हर क्षेत्र के फर्जी त्रुटि कोड 101 को वापस कर दिया गया था।

मुझे लगता है कि आपके प्रश्न का उत्तर देने वाले सभी संदेश संदेश इतने व्यर्थ हैं क्योंकि जब मूल रूप से बनाए गए थे, तो वे प्लेसहोल्डर थे जिन्हें कोई वापस नहीं मिला। आखिरकार लोगों को समझ में आया कि संदेशों के कारण मुद्दों को कैसे ठीक किया जाए लेकिन उन्हें नष्ट न करें।

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

और अगली पीढ़ी के कोडर्स की तरह बहुत सारे (सभी नहीं बल्कि बहुत सारे तरीके से) इसका सामना करते हैं, अगर यह अधिक काम करता है और फ्लैश नहीं जोड़ता है, तो बस इसके लायक नहीं है ...

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

Comments

"... आप हमारे आश्चर्य पर विश्वास नहीं करेंगे जब वस्तुतः हर जगह की फर्जी त्रुटि 101 कोड थी।" आप सही हे। जब आप ठेकेदार आपके निर्देशों का पालन करेंगे तो मुझे आश्चर्य नहीं होगा।

— Odalrick

chances are the users will never write it down... and you will be told "Well it said something about a violation..." यही कारण है कि आप स्टैक ट्रेस वाले त्रुटि रिपोर्ट को स्वचालित रूप से उत्पन्न करने के लिए अपवाद लॉगिंग टूल का उपयोग करते हैं और संभवतः इसे अपने सर्वर पर भी भेजते हैं। मेरे पास एक समय एक उपयोगकर्ता था जो बहुत तकनीकी नहीं था। हर बार वह त्रुटि लकड़हारा से एक संदेश प्रस्तुत करेगा, यह कुछ इस तरह से होगा "मुझे यकीन नहीं है कि मैंने क्या गलत किया है, लेकिन ..." चाहे कितनी बार मैंने समझाया कि इस त्रुटि का मतलब यह था कि बग मेरी तरफ था । लेकिन, मुझे हमेशा उनसे त्रुटि रिपोर्ट मिली!

— मेसन व्हीलर

Answer 6

जबकि मैं इस बात से सहमत हूं कि अपवादों में यथासंभव अधिक जानकारी होनी चाहिए, या कम से कम सामान्य होना चाहिए। तालिका में नहीं मिला मामला, तालिका का नाम अच्छा होगा।

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

तालिका नहीं पाए जाने की स्थिति में, यह आपको बहुत मदद नहीं करेगा यदि आपको बताया जाए कि जिस तालिका को नहीं पाया जा सकता है उसे छात्र कहते हैं, क्योंकि आपके पास ऐसी तालिका नहीं है, और यह स्ट्रिंग आपके कोड में कहीं नहीं है।

लेकिन यदि आप अपवाद को पकड़ते हैं और इसे एसक्यूएल-स्टेटमेंट के साथ रीहैरो करते हैं जिसे आप निष्पादित करने की कोशिश कर रहे थे, तो आप बेहतर बंद हो जाएंगे, क्योंकि यह पता चला है कि आपने नाम फ़ील्ड के साथ रिकॉर्ड डालने की कोशिश की थी 'रॉबर्ट); ड्रॉप टेबल छात्र; (वहाँ हमेशा एक xkcd है!)

तो सूचनात्मक अपवादों से कम का मुकाबला करने के लिए: जो आप करने की कोशिश कर रहे थे, उससे अधिक जानकारी के साथ कोशिश-कैच-रीथ्रो।

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

Comments

जैसे C ++ में आपको throw_with_nestedबहुत उपयोग करना चाहिए ।

— माइल राउत

Answer 7

थोड़ा अलग जवाब देने के लिए: संभवतः अटकलबाजी कोड कल्पना करने के लिए किया गया है:

• फ़ंक्शन X प्राप्त करता है और Y देता है
• यदि X अमान्य है, तो अपवाद Z को फेंक दें

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

Answer 8

अपवादों में एक भाषा है और कार्यान्वयन- विशिष्ट लागत।

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

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

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

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

Comments

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

— मील्स राउत

मुझे पता है कि, लेकिन यह एक तथ्य है कि C ++ अपवाद Ocaml की तरह नहीं हैं, और आप उन्हें उपयोग नहीं करते हैं जैसे आप Ocaml में करते हैं।

— बेसिल स्टारीनेवविच

आप C ++ में नियंत्रण प्रवाह के लिए C ++ अपवादों का उपयोग मुख्य रूप से नहीं करते हैं क्योंकि ऐसा करना कोड को अपठनीय और समझने में कठिन बनाता है।

— माइल्स राउत

Answer 9

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

अपवाद एक त्रुटि हैंडलिंग तंत्र नहीं हैं; वे एक पुनर्प्राप्ति तंत्र हैं।

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

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

मैं यह नहीं कह रहा हूं कि आप हर जगह बस "नया अपवाद फेंक सकते हैं" और इसे अच्छा कह सकते हैं, खराब अपवाद लिखना संभव है। लेकिन अप्रासंगिक सूचनाओं का सही उपयोग करना उनके लिए उपयोगी नहीं है।

Comments

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

— डैनियल हॉलिन्रेके

@DanielHollinrake हां, तालिका का नाम निश्चित रूप से उदाहरणों में सबसे कम अप्रासंगिक है। मैं जिस कोड के साथ काम करता हूं, उसमें इस तरह की समस्या निराशाजनक रूप से आम है और यह देखने के लिए कि टेबल का नाम कैसे पड़ा है, यह बताता है कि क्या गलत है। मैं एक उदाहरण के बारे में सोचने की कोशिश कर रहा हूं कि ये चीजें अपवाद के लिए अप्रासंगिक क्यों हैं; हो सकता है कि मैं इसका इस्तेमाल कर

— सकूं

मैं असहमत हूं। अपवाद को संभालने के लिए अतिरिक्त विवरण की आवश्यकता नहीं हो सकती है क्योंकि आप केवल एप्लिकेशन को क्रैश होने से बचाना चाहते हैं, लेकिन अंत में आपको यह बताना होगा कि यह क्यों काम नहीं किया और इसे ठीक करने में सक्षम है। यदि आपके पास कोई सुराग नहीं है, लेकिन अपवाद प्रकार तो अच्छे डिबगिंग है।

— t3chb0t

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

— Odalrick

@ ग्राहक के लिए यह कोई अर्थ नहीं हो सकता है, लेकिन एक डेवलपर के रूप में मैं हर जानकारी को प्राप्त कर सकता हूं, ;-) फिर शायद एक और उदाहरण: मान लीजिए कि एक SqlExeption होता है और वह सब कुछ है जो आप जानते हैं ... इसे सुधारना बहुत आसान है यदि आप जानते हैं कि कौन सा कनेक्शन स्ट्रिंग या डेटाबेस या टेबल आदि काम नहीं किया .... और यह और भी महत्वपूर्ण है अगर आपका एप्लिकेशन कई डेटाबेस का उपयोग करता है। एक विस्तृत स्टैक ट्रेस के लिए pdb-files को एप्लिकेशन के साथ भेजना आवश्यक है ... यह हमेशा संभव नहीं होता है। इसके अलावा मेमोरी डंप बहुत बड़ी हो सकती है और हमेशा ट्रांसफर नहीं हो सकती है।

— t3chb0t