Чому, схоже, нові програмісти ігнорують повідомлення про помилки компілятора / повідомлення про виключення під час виконання? [зачинено]

Я думаю, ми всі це бачили. Початківці задають питання щодо переповнення стека, які відповідають основним контурам ...

Я намагаюся зробити (дуже розпливчастий опис цілі), але це не спрацьовує / я отримую помилку / виняток. Будь ласка, допоможіть!

Хіба це не химерно, що стільки з них, здається, вважають непотрібним вставляти повідомлення про помилку?

Цікаво, що це за психологія. Що з приводу повідомлень про помилки змушує людей спочатку припускати, що вони марні і не варто звертати на них ніякої уваги?

Відповідь , який я дивлюся на це НЕ «вони не розуміють , повідомлення про помилку». Це не пояснює, чому вони не вважають за краще розповісти нікому, хто може це зрозуміти.

Я думаю, що справжньою причиною є те, що звичайні користувачі комп'ютерів, навіть якщо вони повинні стати програмістами, обумовлені вважати, що вони нічого не можуть зробити з помилками. Подумай над цим. Що роблять непрограмістські типи, коли вони стикаються з криптовалютним повідомленням про помилку *? Вони можуть прочитати його, але дев'ять разів із десяти просто відхилять його та повторюють спробу. Тільки якщо це послідовно не вдається, вони це шукають.

Тому, починаючи вчитися програмуванню, люди не відразу розуміють, що помилка, яку вони отримують, містить корисну інформацію про те, як її виправити; і так, хоча помилки компілятора можуть бути нечитабельними навіть для підготовленого професіонала (я дивлюся на вас, метапрограмування шаблонів C ++), принаймні вони дають загальну вихідну точку, і як тільки ви кілька разів бачите ту саму помилку , ви завжди будете знати, що зробили, щоб викликати це.

* Чесно кажучи, хоча більшість повідомлень про помилки виглядає на Joe Average на зразок "Помилка X2412: Неможливо встановити фронікальне інтерплатформування dongledash: будь ласка, перевірте налаштування bandersnatch або зверніться до системного адміністратора."

Я думаю, якщо це справжній початківець, є хороший шанс, що вони не знають, що взагалі є повідомлення про помилку. Вони лише знають, що це не працює і що є помилка. Наприклад, у студії Visual вони можуть не бачити тієї частини екрану.

В основному вони не знають, яка частина наявної у них інформації корисна, щоб з'ясувати, в чому проблема. Якщо вони це зробили, є більший шанс, вони могли б самі це виправити, а не запитувати про це в першу чергу.

Я думаю, що задавати питання та вирішувати проблеми - це навичка, яку потрібно засвоїти, а для професійних розробників - це важливий навик, який просто не навчається досить часто.

Так само як код, який ви пишете, коли ви вперше починаєте цю професію, буде жахливим порівняно з кодом, який ви пишете сьогодні, питання, які ви задаєте, будуть жахливими порівняно з тим, як ви їх сьогодні задаєте.

Коли ви починаєте, легко переграти всю інформацію, яку ви вивчаєте, і коли все не збирається планувати, важко дізнатися, яка інформація є актуальною, а що ні. Це велика частина причини, чому початківці не можуть вирішити проблему для себе в першу чергу!

Це більше стосується IRC, ніж веб-сайти, такі як переповнення стека, що набагато рідше.

Я думаю, що причина цього полягає в тому, що люди почувають себе краще, якщо вони знають, що людина, зокрема, зацікавлена ​​у їх проблемі та готовий допомогти їм. Тож вони починають з того, що у них є проблеми, але вони не вникають у деталі, поки хтось їх не запитає, бо бояться, що інакше все одно не отримають відповіді.

Іноді (не у випадку помилок компілятора) така поведінка насправді має сенс. Якщо у мене є велика складна проблема, я переконуюсь, що хтось спочатку слухає, перш ніж написати довге пояснення, яке ніхто не прочитає.

Оскільки помилки / винятки компілятора вимагають знати, що ви робите неправильно, щоб виправити це. Вони призначені для програмістів, які оглядають речі, а не для людей, які їх не розуміють.

Вони також не завжди є найбільш очевидними. Помилка типу "несподіване якщо" не така інтуїтивна. "Але що, якщо має бути там", - це відповідь новачка. Досвідченіший програміст знає, що це означає, що він забув крапку з комою в попередньому рядку.

Я не думаю, що це лише новачки. У мене є співробітники з багаторічним досвідом роботи, які, здається, дивляться лише на номер рядка, коли отримують помилку компілятора, а потім намагаються самі розібратися в решті (часто, намагаючись вуду на зразок "додамо дужки" або "давайте порушимо це на два твердження ").

Моє підозріння полягає в тому, що це насправді не має глибокого розуміння правил мови, так що загалом щільний опис помилки не має великого значення. expression must be a modifiable lvalueздається досить марною інформацією, якщо ви насправді не знаєте, що таке значення .

Що з приводу повідомлень про помилки змушує людей спочатку припускати, що вони марні і не варто звертати на них ніякої уваги?

Ну, для мене це була молодь, наповнена збоєм програмного забезпечення Windows 95 із повністю непроникними повідомленнями про помилки, які зазвичай закінчувалися приблизно 150 рядками шістнадцяткових знаків.

Я переживаю той самий досвід кожного разу, коли отримую чудовий криптований слід стека Java, який буде містити 40 рядків лайнера компілятора та помилок у сплячому стані, і серед них дуже добре приховано фактичне посилання на те, де в моєму додатку помилка.

Причина, через яку люди ігнорують повідомлення про помилки та сліди стека, часто є повідомленнями про помилки, а сліди стека - непропорційно складними порівняно зі складністю проблеми. Немає причин пропускати 150 рядків лайно через мій екран, коли я пропускаю напівкрапку.

Я викладаю деякі курси з Linux для Junior Sysadmins та програмування на PHP та Mysql. Більшість студентів на PHP знають, що є помилка, оскільки вони бачать некрасиве повідомлення на екрані. Але вони здаються не в змозі його прочитати. Зазвичай я переходжу до їх екрану, коли вони мені кажуть, що щось не працює, я читаю помилку на екрані, кажу їм, щоб її прочитали, підкреслюючи файл та рядок, помічені на помилці, і кажу їм, щоб вони шукали там. Вони виправляють помилку, але коли з’являється інша помилка, застосовується та сама процедура ... зітхання ...

Під час курсу Linux іноді вони навіть не помічають помилки. Вони вводять якусь команду, деякі рядки з’являються на екрані і продовжують наступну команду. Коли пізніше деякі команди, нарешті, вони помічають, що щось не працює, і я піднімаю руки, я підходжу, прокручую консоль і вказую на команду, яка вийшла з помилкою через погані параметри чи що завгодно. Їх обличчя: здивування. Тож легкою частиною для моїх учнів Linux було те, щоб вони помітили, коли виникає помилка, використовуючи деяку модифікацію підказки bash, щоб зробити її різною, коли з’являється помилка, як ця . Тепер, змусити їх прочитати повідомлення про помилку, як тільки вони побачать це, це інший бій (такий же, як і зі студентами PHP) ...

Я вважаю, що вони просто не звикли думати про коди помилок, і до того моменту, коли вони дістануться місця, де вони повинні їх надати, вони вже відчувають, що вони повністю пояснили проблему, а тому ще рідше зупиняються і замислюються над тим, чи вони повинні дати додаткову інформацію.

Поставлення запитання включає кілька етапів, і вони найбільш логічно розташовані в такому порядку:

1. вам потрібно описати, що ви робили
2. вам потрібно описати, як ви це робили
3. вам потрібно описати, що сталося, коли воно не вдалося (або як воно не вдалося)
4. вам потрібно надати післясмертний звіт

Звіт про смерть - це повідомлення про помилку, яке знаходиться в самому кінці. До того моменту, коли новачки досягають цього пункту, вони закінчуються розумовим завданням пояснити свою проблему і, швидше за все, щось пропустять (для новачків існує проблема перевантаження інформацією). Далі, в цей момент вони вже відчувають, що вони описали всі аспекти проблеми, і вони мають звичні звички, які заважають їм пам’ятати про коди помилок: адже в інших сферах життя немає кодів помилок, тому вони не звикли подумай над ними.

Можливо також, що навіть якщо вони пам’ятають про коди помилок, вони здаються занадто виразними, щоб мати фактичну користь. Що таке помилка 034982? Це насправді комусь щось означає? І чи дійсно щось додає до того детального опису того, що я робив, як я це робив і як це не вдалося? Похмуро ця інформація сама по собі стоїть.

Тому що для більшості мов більшість повідомлень компілятора / виконання не мають сенсу. (Особливо на C ++ та Java, я дивлюся на вас!) Визначення правильних помилок, як правило, у списку пріоритетів мовного дизайнера досить низько. Правильне ставлення до речі, як правило, є більшим пріоритетом, і багато часу вони не заважають полірувати дрібні деталі.

Це одна з причин, чому мені подобається працювати в Delphi. Вся мова сповнена уваги до дрібниць, зокрема помилок. Повідомлення компілятора мають сенс. Повідомлення про помилки під час виконання мають сенс. Сліди стеків мають сенс. Це одна з речей, яка робить її, на сьогоднішній день, найпростішою мовою налагодження, з якою я коли-небудь працював.