नए प्रोग्रामर कंपाइलर एरर मैसेज / रनटाइम अपवाद मैसेज को नजरअंदाज क्यों करते हैं? [बन्द है]


27

मुझे लगता है कि हमने यह सब देखा है। शुरुआती अतिप्रवाह पर सवाल पूछते हैं जो मूल रूपरेखा का पालन करते हैं ...

मैं करने की कोशिश कर रहा हूँ (लक्ष्य का बहुत अस्पष्ट वर्णन) लेकिन यह काम नहीं करता / मुझे एक त्रुटि / अपवाद मिलता है। कृपया सहायता कीजिए!

क्या यह विचित्र नहीं है कि उनमें से कई त्रुटि संदेश को चिपकाने के लिए इसे अनावश्यक मानते हैं?

मुझे आश्चर्य है कि इसका मनोविज्ञान क्या है। यह त्रुटि संदेशों के बारे में क्या है जो लोगों को शुरू में यह मान लेता है कि वे बेकार हैं और कोई ध्यान देने लायक नहीं है?

मैं जो उत्तर ढूंढ रहा हूं वह "त्रुटि संदेश समझ में नहीं आता है"। यह स्पष्ट नहीं करता है कि वे किसी और को बताने पर विचार क्यों नहीं करेंगे जो इसे समझ सकता है।

जवाबों:


21

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

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

* ईमानदारी से, हालांकि, अधिकांश त्रुटि संदेश जो "एवरेज X2412:" की तरह औसत एवरेज दिखते हैं, जो फ्रॉबनिकेटरी इंटरप्लाकिंग डोंगलडैश स्थापित करने में असमर्थ हैं: कृपया बैंडर्सनैच सेटिंग्स को सत्यापित करें या अपने सिस्टम एडमिनिस्ट्रेटर से संपर्क करें। "


6
यदि आप अपने सॉफ़्टवेयर में उस त्रुटि संदेश का उपयोग करते हैं तो क्या आप बुरा मानते हैं?
I.devries

12

मुझे लगता है कि अगर यह एक सच्ची शुरुआत है तो एक अच्छा मौका है कि वे नहीं जानते कि एक त्रुटि संदेश है। वे केवल यह जानते हैं कि यह नहीं चलता है और एक त्रुटि है। उदाहरण के लिए विज़ुअल स्टूडियो में वे स्क्रीन के उस हिस्से को नहीं देख सकते हैं।

मूल रूप से वे यह नहीं जानते हैं कि उनके पास जो जानकारी उपलब्ध है, वह पता लगाने के लिए उपयोगी है कि समस्या क्या है। यदि उन्होंने ऐसा किया तो बेहतर मौका होगा कि वे इसे स्वयं ठीक कर सकें और पहली बार में इसके बारे में न पूछें।


यह एक उचित विचार है, लेकिन क्या यह वास्तव में इस तरह के सवालों की उच्च मात्रा की व्याख्या करता है?
तिमवी

@ टिमिवी: शायद यह उचित त्रुटि जानकारी के साथ प्रश्नों की अपेक्षाकृत कम मात्रा की व्याख्या करता है। बुरे प्रश्नों की पूर्ण मात्रा सामुदायिक आकार के सापेक्ष है।
ब्रायन आर। बॉडी

6

मुझे लगता है कि प्रश्न पूछना और समस्या निवारण एक कौशल है जिसे सीखने की आवश्यकता है, और पेशेवर डेवलपर्स के लिए, यह एक महत्वपूर्ण कौशल है जिसे बस अक्सर पर्याप्त नहीं सिखाया जाता है।

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

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


5

यह आईआरसी पर ऑनलाइन वेबसाइटों की तुलना में अधिक लागू होता है जैसे कि स्टैक ओवरफ्लो, जो बहुत अधिक दुर्लभ है।

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

कभी-कभी (संकलक त्रुटियों के मामले में नहीं) यह व्यवहार वास्तव में समझ में आता है। अगर मुझे कोई बड़ी जटिल समस्या आती है तो मैं यह सुनिश्चित करूंगा कि कोई व्यक्ति लंबी व्याख्या लिखने से पहले सुन रहा है जिसे कोई नहीं पढ़ेगा।


देवताओं, मैं चाहता हूं कि यह अभी भी एसओसी की तुलना में अधिक आईआरसी पर लागू हो ...
फ़ेलिक्स गगनोन-ग्रेनियर

3

क्योंकि कंपाइलर त्रुटियों / अपवादों को यह जानना आवश्यक है कि आप इसे ठीक करने के लिए क्या कर रहे हैं। वे प्रोग्रामर के लिए हैं जो सामान की अनदेखी करते हैं, उन लोगों के लिए नहीं जो उन्हें नहीं समझते हैं।

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


ज़रूर - लेकिन कुछ सोचने के बीच अंतर है कि यह गुप्त है और यह सोचना बेकार है।
डेविड थॉर्नले

1
@ डेविड: क्या उपयोग एक गुप्त त्रुटि संदेश है? ... ज्यादा नहीं।
मॉर्गन हेरलॉकर

1
@Irontool: SO पर पूछने पर इसे उद्धृत करें। इसे काटकर एक वेब खोज में पेस्ट करें। यहां तक ​​कि अगर आप इसे नहीं समझते हैं, तो यह एक जादू कुकी के रूप में कार्य कर सकता है।
डेविड थॉर्नले

2

मुझे नहीं लगता कि यह केवल newbies है। मेरे पास वर्षों के अनुभव वाले सहकर्मी हैं जो केवल एक कंपाइलर की त्रुटि मिलने पर लाइन नंबर को देखते हैं, फिर बाकी लोगों को जानने की कोशिश करते हैं (अक्सर इस तरह की कोशिश करके "जैसे कि कोष्ठक जोड़ते हैं" या "चलो इसे तोड़ते हैं" दो बयानों में ")।

मेरा संदेह यह है कि यह वास्तव में भाषा के नियमों की गहरी समझ नहीं होने के कारण आता है, ताकि आम तौर पर त्रुटि के घने विवरण का अधिक अर्थ न हो। expression must be a modifiable lvalueबहुत बेकार जानकारी की तरह लगता है अगर आप वास्तव में नहीं जानते कि एक अंतराल क्या है।


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

1

यह त्रुटि संदेशों के बारे में क्या है जो लोगों को शुरू में यह मान लेता है कि वे बेकार हैं और कोई ध्यान देने लायक नहीं है?

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

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

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


2
बहुत अच्छी तरह से छिपा? बस अपने पैकेज के नाम के लिए स्कैन करें।
बार्ट वैन ह्युकेलोम सेप

1

मैं जूनियर Sysadmins के लिए लिनक्स पर कुछ पाठ्यक्रम पढ़ा रहा हूं, और PHP और Mysql के साथ प्रोग्रामिंग कर रहा हूं। PHP पर अधिकांश छात्रों को पता है कि वहाँ एक त्रुटि है क्योंकि वे स्क्रीन पर बदसूरत संदेश देखते हैं। लेकिन वे इसे पढ़ पाने में असमर्थ लगते हैं। आमतौर पर मैं उनकी स्क्रीन पर जाता हूं जब वे मुझे बताते हैं कि कुछ काम नहीं कर रहा है, मैंने स्क्रीन पर त्रुटि पढ़ी, उन्हें इसे पढ़ने के लिए कहा, त्रुटि पर नोट की गई फ़ाइल और लाइन पर जोर दिया और उन्हें वहां देखने के लिए कहा। वे त्रुटि को सुधारते हैं, लेकिन जब एक और त्रुटि दिखाई देती है, तो वही प्रक्रिया लागू होती है ... आह ...

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


0

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

प्रश्न पूछने में कुछ चरण शामिल हैं, और वे इस क्रम में सबसे अधिक तार्किक रूप से व्यवस्थित होते हैं:

  1. आपको यह बताने की जरूरत है कि आप क्या कर रहे थे
  2. आपको यह वर्णन करने की आवश्यकता है कि आप कैसे कर रहे थे
  3. आपको यह बताने की आवश्यकता है कि जब यह विफल हुआ (या यह कैसे विफल हुआ)
  4. आपको पोस्टमार्टम रिपोर्ट देने की आवश्यकता है

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

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


आप किस पर्यावरण / संकलक / रूपरेखा का उपयोग कर रहे हैं जिसमें विशुद्ध रूप से संख्यात्मक त्रुटि कोड हैं? oO
तिमवी सिप

मैं ऐसे एक आईडीई का उपयोग नहीं कर रहा हूं। त्रुटि संदेश को केवल गुप्त (अनहेल्दी) के रूप में समझा जा सकता है, या उपरोक्त विवरण के रीफ़्रैशिंग की तरह लग सकता है (जानकारी नहीं जोड़ता है)।
एप्सिलॉनवेक्टर

0

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.