उपयोगी त्रुटि संदेशों के साथ डेवलपर की समस्याएं क्या हैं? [बन्द है]

Question

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

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

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

एक अन्य उम्मीदवार, SQL सर्वर (और mySQL) भी प्यारा string or binary data would be truncatedत्रुटि संदेश और समकक्ष है। बहुत बार, एसक्यूएल बयान की एक साधारण गड़बड़ी जो उत्पन्न हुई थी और तालिका दिखाती है कि कौन सा कॉलम अपराधी है। यह हमेशा ऐसा नहीं होता है, और यदि डेटाबेस इंजन त्रुटि पर उठाया जाता है, तो यह हमें उस समय क्यों नहीं बचा सकता है और हमें केवल यह बताता है कि यह कौन सा शापित स्तंभ था? इस उदाहरण पर, आप तर्क दे सकते हैं कि इसकी जाँच करने के लिए एक प्रदर्शन हिट हो सकता है और यह लेखक को प्रभावित करेगा। ठीक है, मैं खरीद लूंगा। कैसे के बारे में, एक बार जब डेटाबेस इंजन को पता चलता है कि कोई त्रुटि है, तो यह एक त्वरित तुलना करता है, इस तथ्य के बाद, उन मूल्यों के बीच जो संग्रहित होने जा रहे थे, बनाम कॉलम की लंबाई। फिर उस उपयोगकर्ता को प्रदर्शित करें।

ASP.NET की डरावनी तालिका एडेप्टर भी दोषी हैं। क्वेरीज़ को निष्पादित किया जा सकता है और किसी को यह कहते हुए एक त्रुटि संदेश दिया जा सकता है कि कहीं न कहीं एक बाधा का उल्लंघन किया जा रहा है। उसके लिए धन्यवाद। डेटाबेस के खिलाफ मेरे डेटा मॉडल की तुलना करने का समय, क्योंकि डेवलपर्स बहुत रोशन हैं यहां तक ​​कि एक पंक्ति संख्या, या उदाहरण डेटा प्रदान करने के लिए। (रिकॉर्ड के लिए, मैं इस डेटा का उपयोग विधि का उपयोग करना चाहते कभी नहीं पसंद से , यह सिर्फ एक परियोजना मैं विरासत में मिली है!)।

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

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

डेवलपर्स को क्यों लगता है कि यह ठीक है, इस दिन और उम्र में, जब कोई त्रुटि होती है तो नंगे न्यूनतम राशि प्रदान करने के लिए?

2011 लोग है, आने पर ।

Comments

वाह, यह काफी शेख़ी है।

— जॉर्ज मैरियन

@ जॉर्ज, क्या आप बता सकते हैं कि मैंने एक लंबा समय बिताया है, जो वास्तव में तेजी से हल किया जा सकता है, एक उचित त्रुटि को देखते हुए कुछ समय बिताने के लिए? :)

— मू-रस

मैं गहरी सांसों का सुझाव देता हूं, शायद कुछ योग और ध्यान। :) (यह कहा, मैं जानता हूं कि आप कैसा महसूस करते हैं।)

— जॉर्ज मैरियन

+1 - "स्ट्रिंग या बाइनरी डेटा को छोटा किया जाएगा" हमेशा मुझे पागल करता है!

— k25

Answer 1

जबकि खराब त्रुटि संदेशों के बहुत सारे उदाहरण हैं जो बस नहीं होने चाहिए, आपको यह ध्यान रखना चाहिए कि वह जानकारी प्रदान करना संभव नहीं है जिसे आप देखना चाहते हैं।

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

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

Comments

+1 मैंने सूचना अधिभार पहलू के बारे में भी नहीं सोचा।

— रयान हेस

मैंने अपनी पोस्ट में बताया कि मैं समझ सकता हूं कि क्यों कुछ लोगों को लगता है कि एंड-यूज़र के लिए शब्दशः उनके लिए बेकार हो सकता है। लेकिन क्या आप कह रहे हैं कि एक एपीआई (एजी ASP.NET के एडेप्टर) के अंतिम-उपयोगकर्ता, या एक डेटाबेस इंजन (SQL-Server) क्रिया त्रुटियों को नहीं चाहते हैं? कुछ ऐसा जो हमें खोए हुए समय के संभावित घंटों को बचाएगा? मुझे यह वाक्य पसंद आया, वैसे :)

— मू-जूस

@George, सूचना अधिभार के संबंध में भी है और यह अंतिम उपयोगकर्ता के लिए उपयोगी है, फिर से मैं एक शब्द-प्रोसेसर के उपयोगकर्ता को पूर्ण-स्टैक-ट्रेस पर नहीं फेंकने के लिए एक मामला देख सकता हूं, ऐसा नहीं है कि उनके पास एक भूरा-पतलून है। और सोचें कि उन्होंने इंटरनेट हटा दिया है। हालाँकि, आपने लॉग फ़ाइल में जटिल जानकारी के साथ एक उत्कृष्ट विकल्प प्रदान किया है। अब उस संदेश को जोड़ने की जरूरत है For further information, see log20111701.txt। यह सही दिशा में एक कदम होगा।

— मू-जूस

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

— जॉर्ज मैरियन

@moo समस्या का मूल यह है कि यह हमेशा स्पष्ट नहीं होता है कि जानकारी कितनी उपयोगी है। आपके द्वारा दिए गए उदाहरण स्पष्ट प्रतीत होते हैं। हालाँकि, सामान्य मामले में इसका विस्तार करना आसान नहीं है।

— जॉर्ज मैरियन

Answer 2

डेवलपर्स त्रुटि संदेश लिखने के लिए सही लोग नहीं हैं।

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

Comments

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

— MIA

Answer 3

धर्मार्थ दृश्य:

• डेवलपर ने कोड के साथ मिलकर काम किया और किसी ऐसे व्यक्ति को समझने के लिए संघर्ष किया, जिसके पास उसकी समझ नहीं थी। परिणामस्वरूप उन्हें लगता है कि त्रुटि संदेश ठीक हैं, उनके पास केवल संदर्भ का एक अच्छा फ्रेम नहीं है जिसके द्वारा उन्हें न्याय करना है।

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

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

अपरिवर्तनीय दृश्य:

• त्रुटि संदेश और त्रुटि हैंडलिंग सुस्त हैं, पर काम करने के लिए और अधिक दिलचस्प चीजें हैं और मेरे बॉस अगली चीज के बारे में मेरी पीठ पर हैं। मैं इस कोड को समझता हूं, मैं ठीक हो जाऊंगा, अगला लड़का अंत में यह काम करेगा और मैं तब तक यहां से बाहर रहूंगा, इसलिए यह मेरी समस्या नहीं है।

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

Comments

मैं समझता हूं कि आप कई एंड-यूज़र मामलों में कहां से आ रहे हैं। हालाँकि, मैं अपने मूल पोस्ट में उल्लिखित मामलों को डेटाबेस के खिलाफ कोड लिखने के दौरान अक्सर हो सकता है। एंड-यूज़र एप्लिकेशन जैसे शब्द-प्रोसेसर या कंप्यूटर गेम के संबंध में, त्रुटियों को आम तौर पर तब तक नहीं होना चाहिए जब तक कि कुछ बुरा नहीं हो रहा है, और फिर भी त्रुटि का मतलब अंत-उपयोगकर्ता के लिए कुछ भी नहीं हो सकता है Process Handle Raped By Spawned Injector, Quitting SYstem.... ( .... उपयोगकर्ता: "wtf मैंने किया?`)। लेकिन SQL सर्वर / ASP.NET के मामले में, मुझे लगता है कि और प्रयास किए जा सकते थे :)

— मू-जूस

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

— जॉन हॉपकिंस

कुछ मामले तुच्छ नहीं हो सकते हैं। मैं कहीं न कहीं एक साधारण सा कोड है जो उस string/binary dataत्रुटि को पकड़ लेता है जो उक्त तालिका से सभी कॉलम जानकारी खींचती है, अतीत के मूल्यों की जांच करती है और दिखाती है कि कौन से कॉलम का उल्लंघन हुआ होगा। यह तुच्छ था। शायद मैं बहुत ज्यादा कुतिया हूँ क्योंकि मेरे मामले-उदाहरण तुच्छ हैं, लेकिन मैं पूरी तरह से समझता हूं कि यह हमेशा मामला नहीं होता है। कैसे हम बलात्कार की प्रक्रियाओं से पैदा हुए इंजेक्टरों को रोकना मुश्किल हो सकता है :)

— मू-रस

Answer 4

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

Comments

आह, हाँ, अच्छी बात है। यह कभी भी लागत की चिंता का विषय है।

— जॉर्ज मैरियन

मैं एक लागत परिप्रेक्ष्य (और इसे लानत दे सकता हूं, इसका मतलब यह नहीं है कि मुझे इसे पसंद करना है)। मैं एसक्यूएल सर्वर या ASP.NET के डेवलपर्स के दृष्टिकोण से बात नहीं कर सकते, लेकिन मुझे पता है कि यह नहीं ले करता है कि एक स्तंभ नाम प्रदान करने के लिए ज्यादा अतिरिक्त प्रयास। मैं मानता हूँ कि, मेरे सरल उदाहरण के लिए, यह एक घंटे में हल किया जा सकता है। फिर अन्य 1000 त्रुटियां हैं जो उत्पन्न हो सकती हैं। लेकिन वे कम से कम आम लोगों के साथ शुरू कर सकते थे :)

— मू-जूस

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

— इचथियो

कुछ स्तर पर, यह मान्य हो सकता है, लेकिन एक ही समस्या यह भी सरल पर्ल स्क्रिप्ट में फसलों जहां बस $ जोड़ने! त्रुटि संदेश के लिए काफी मददगार होगा। यह सस्ता लिखने के लिए (डेवलपर के समय के संदर्भ में) है: की तुलना में यह पूरी तरह से बेकार लिखना है 'मरने "सका खुला $ पथ नहीं"' 'मरने "$ पथ $!"'

— विलियम Pursell

Answer 5

मैं सहमत हूं कि त्रुटि संदेश यथासंभव विशिष्ट होना चाहिए।

सामान्य त्रुटि संदेशों का एक कारण संभवतः त्रुटि कोड का उपयोग है। अपवादों का उपयोग करते समय आप त्रुटि संदेश में सभी आवश्यक पारित करने के लिए स्वतंत्र हैं। रिटर्न कोड का उपयोग करना एक कॉलमनाम को एनकोड करने के लिए कोई जगह नहीं है। शायद त्रुटि को एक सामान्य फ़ंक्शन द्वारा नियंत्रित किया जाता है जो संदर्भ को नहीं जानता है और बस त्रुटि कोड को एक स्ट्रिंग में अनुवाद करता है।

Comments

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

— इचथियो

btw ... इस तंत्र में अजीब त्रुटि संदेशों की एक पूरी कक्षा होती है - "मॉड्यूल में गंभीर गलती -567 की तर्ज पर dwarf678: कोई त्रुटि नहीं

— मिली

Answer 6

• कभी-कभी बहुत अधिक जानकारी एक सुरक्षा जोखिम हो सकती है; आपको पता नहीं है कि त्रुटि संदेश कौन पढ़ रहा है
• कभी-कभी अपवाद को फेंकने वाला ऑपरेशन इतना जटिल है कि कोड की गति / जटिलता को नकारात्मक प्रभावित किए बिना एक सार्थक संदेश प्राप्त करना असंभव है

Comments

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

— मू-जूस

यह सच है, मुझे लगता है कि आप जानकारी के लिए खोज कर सकते हैं एक बार कुछ ऐसा हुआ जो आपको आवश्यकता हो सकती है, पर नज़र रखने के बजाय । हालाँकि, यदि आप नेस्टेड लूप में हैं तो इंडेक्स / इंडेक्स कैप्चर करने में समस्या हो सकती है।

— स्टुपेरयूजर

पहले बिंदु के लिए -1, जिसके साथ मैं सहमत नहीं हूं, दूसरे बिंदु के लिए +1।

— जॉन हॉपकिंस

@jon लॉगिन त्रुटियों बनाम अधिक विशिष्ट त्रुटि संदेशों के लिए एक सामान्य त्रुटि संदेश के विपरीत है जो वास्तव में आपको बताता है कि क्या गलत हुआ। उदाहरण के लिए "हम उस उपयोगकर्ता नाम / पासवर्ड संयोजन को नहीं ढूंढ सके" बनाम "आपने गलत पासवर्ड दर्ज किया है।" / "यह उपयोगकर्ता नाम मौजूद नहीं है।" मुझे ASP.NET में एक भेद्यता याद है, जहाँ त्रुटि संदेश एन्क्रिप्शन कुंजी को क्रैक करने में वास्तव में उपयोगी था।

— जॉर्ज मैरियन

@ जॉर्ज - मैं उस उदाहरण से सहमत हूं लेकिन मुझे नहीं लगता कि यह व्यापक है। एक बार जब आपको एक आवेदन करने की अनुमति दी जाती है तो जोखिम का एक निश्चित स्तर गायब हो जाता है क्योंकि आप मान सकते हैं कि व्यक्ति (ए) अधिकृत है और (बी) वास्तविक आवेदन से सबसे ज्यादा क्या प्राप्त कर सकता है।

— जॉन हॉपकिंस

Answer 7

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

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

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

आपके द्वारा दिए गए ठोस उदाहरण से संबंधित करने के लिए: यदि, त्रुटि के बिंदु पर, तालिका स्तंभ का नाम और प्रकार ज्ञात होगा, और आवश्यक स्थान की लंबाई के अलावा, तो कोई कारण नहीं होगा एक त्रुटि उठा, यह नहीं होगा? हम स्थिति को ठीक कर सकते हैं और योजना के अनुसार आगे बढ़ सकते हैं। तथ्य यह है कि हम एक त्रुटि जुटाने के लिए मजबूर हैं, हमें दिखाता है कि मामले भटक गए थे। बहुत तथ्य यह है कि इन informations हाथ में नहीं हैं अपवाद है ।

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

नियंत्रण के नुकसान की संभावना इस तथ्य से उपजी है कि हम योजनाबद्ध और क्रमबद्ध तरीके से काम कर रहे हैं ।

Comments

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

— मू-रस

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

— Ichthyo

Answer 8

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

यह मुझे लगता है कि भले ही यह उपयोगकर्ताओं के लिए प्रस्तुत नहीं किया गया था, यह हमारे लिए बहुत समय सुरक्षित होगा यदि देव टीम एक त्रुटि संदेश इंडेक्स डॉक या डेटाबेस में नोट जोड़ देगी जब भी वे एक नया जोड़ते हैं तो यह इसे बना देगा। हमारे लिए ग्राहकों की समस्याओं का कारण खोजने और उन्हें समय बचाने के लिए बहुत जल्दी ...

Comments

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

— इचथियो

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

— जीन पिंडार

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

— इचथियो

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

— ग्लेनट्रॉन

Answer 9

आप जो समस्या देख रहे हैं, वह वास्तव में उचित एनकैप्सुलेशन और सूचना छिपाने के दुष्प्रभावों में से एक है।

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

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

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

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

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

Comments

@GLLosa, यह एक महान जवाब है और एक जिसे मैंने नहीं माना था। उस ने कहा (और मैं यहां एक पूर्ण कोड उदाहरण प्रदान नहीं कर सकता), जब मुझे वह IOException मिलता है, इससे पहले कि मैं अपना फेंक दूं GenericException, मैं 1) Processesप्रक्रियाओं की सूची के लिए सबसिस्टम से पूछ सकता हूं । 2) प्रत्येक प्रक्रिया से पूछें कि वे किस डेटाबेस का उपयोग कर रहे हैं। 3) डेटाबेस के साथ प्रक्रिया का मिलान करें जिसे मैं अधिलेखित करने की कोशिश कर रहा हूं, 4) एक DatabaseInUse(dbName, processName, applicationNameअपवाद को फेंक दें । :)

— मू-रस

निश्चित रूप से संभव है; लेकिन इस प्रक्रिया (विशेष रूप से नेटवर्क पर) के लिए DB से मिलान करने का कोड जटिल / धीमा / त्रुटि प्रवण हो सकता है, जिसके परिणामस्वरूप कुछ एडिटोनल फ्रस्ट्रेशन हो सकता है ("मैं स्थानीय (* #% ^) को पुनर्स्थापित करने का प्रयास कर रहा हूं!" % फ़ाइल !!!! मुझे ऐसा क्यों लगता है कि नेटवर्क शेयर एक समान नहीं हैं! ??! "!"

— GWLlosa

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

— इचथियो

यह उदाहरण वास्तव में बहुत शिक्षाप्रद है: आमतौर पर इस तरह के कैच हैंडलर में, आप यह भी सुनिश्चित नहीं कर सकते हैं कि कोशिश ब्लॉक में कौन सा हिस्सा विफल रहा (आमतौर पर कई हिस्से हैं जो IOException पैदा कर सकते हैं)। इसके अलावा, यह बहुत संभावना है कि उस स्थान पर आप फ़ाइल का नाम नहीं बता सकते हैं, ऐसा न हो कि आप बता सकें कि कौन सी तार्किक तालिका इस फ़ाइल से मेल खाती है।

— इचथियो

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

— मू-रस

Answer 10

मेरा पसंदीदा (70 के अंत में वापस) Univac फोरट्रान IV संकलक था, जब गैर-अंक पढ़ता था, तो विश्वासपूर्वक घोषणा की गई थी

अर्थहीन डेटा की व्याख्या का प्रयास किया गया था

Comments

+1, एकदम शानदार! यह उस तरह की त्रुटि है जो आपको बस छोड़ देना चाहती है और फिजी में मुर्गियों को उठाना और उठाना चाहती है।

— मू-रस

वास्तव में, यह त्रुटि संदेश 100% सटीक है - यदि आप अधिक संदर्भ के साथ अधिक मैत्रीपूर्ण संदेश चाहते हैं, तो आपको कुछ अनुमान और हेरास्टिक्स में निर्माण करने की आवश्यकता है; इस तरह से आप भ्रामक त्रुटि संदेशों की संभावना को जोड़ते हैं ..

— Ichthyo

Answer 11

मेरा मानना ​​है कि अधिकांश त्रुटि संदेश वास्तव में प्रोग्रामर (स्व) उन्मुख गौरवशाली डिबगिंग कोड / प्रिंटफ स्टेटमेंट हैं।

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

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

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

Answer 12

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

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

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

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