Dlaczego wydaje się, że nowi programiści ignorują komunikaty o błędach kompilatora / komunikaty o wyjątkach czasu wykonywania? [Zamknięte]

Myślę, że wszyscy to widzieliśmy. Początkujący zadają pytania na temat przepełnienia stosu, które są zgodne z podstawowym schematem ...

Próbuję to zrobić (bardzo niejasny opis celu), ale to nie działa / otrzymuję błąd / wyjątek. Proszę pomóż!

Czy to nie dziwne, że tak wielu z nich uważa, że ​​wklejanie komunikatu o błędzie nie jest konieczne?

Zastanawiam się, jaka jest tego psychologia. Co takiego jest w komunikatach o błędach, które powodują, że ludzie początkowo zakładają, że są bezużyteczni i nie warto na nie zwracać uwagi?

Odpowiedź, której szukam, to nie „nie rozumieją komunikatu o błędzie”. To nie wyjaśnia, dlaczego nie rozważaliby powiedzenia nikomu, kto mógłby to zrozumieć.

Myślę, że prawdziwym powodem jest to, że zwykli użytkownicy komputerów, nawet jeśli powinni zostać programistami, są uwarunkowani przekonaniem, że nie mogą nic zrobić z błędami. Pomyśl o tym. Co robią typy nieprogramiści, gdy napotkają tajemniczy komunikat o błędzie *? Mogą to przeczytać, ale dziewięć razy na dziesięć po prostu ją odrzucą i spróbują ponownie. Tylko wtedy, gdy konsekwentnie zawiedzie, sprawdzą.

Dlatego, kiedy zaczynają się uczyć programowania, ludzie nie od razu zdają sobie sprawę, że zgłaszany błąd zawiera przydatne informacje, jak to naprawić; i tak, chociaż błędy kompilatora mogą być prawie nieczytelne nawet dla wyszkolonego profesjonalisty (patrzę na ciebie, metaprogramowanie szablonu C ++), przynajmniej zapewniają one ogólny punkt wyjścia, a po kilkakrotnym zobaczeniu tego samego błędu , zawsze będziesz wiedział, co zrobiłeś, aby to spowodować.

* Szczerze mówiąc, większość komunikatów o błędach wygląda na „Średnia Joe”, np. „Błąd X2412: Nie można ustanowić frobnicatory dongledash międzyplatformowego: sprawdź ustawienia bandersnatch lub skontaktuj się z administratorem systemu”.

Myślę, że jeśli to prawdziwy początkujący, istnieje duża szansa, że ​​nie wiedzą, że w ogóle pojawia się komunikat o błędzie. Wiedzą tylko, że to nie działa i że wystąpił błąd. Na przykład w Visual Studio mogą nie widzieć tej części ekranu.

Zasadniczo nie wiedzą, która część posiadanych informacji jest przydatna, aby dowiedzieć się, na czym polega problem. Gdyby to zrobili, byłaby większa szansa, że ​​mogliby to naprawić samodzielnie i nie pytać o to w pierwszej kolejności.

Myślę, że zadawanie pytań i rozwiązywanie problemów to umiejętność, której należy się nauczyć, a dla profesjonalnych programistów to ważna umiejętność, której po prostu nie uczy się wystarczająco często.

Tak jak kod, który piszesz, kiedy zaczynasz w tym zawodzie, będzie okropny w porównaniu z kodem, który piszesz dzisiaj, pytania, które zadajesz, będą okropne w porównaniu z tym, jak je zadajesz dzisiaj.

Kiedy zaczynasz, łatwo przytłoczyć się wszystkimi informacjami, których się uczysz, a kiedy nie planujesz, trudno jest wiedzieć, które informacje są istotne, a które nie. Jest to duża część powodu, dla którego początkujący nie mogą samodzielnie rozwiązać problemu!

Dotyczy to bardziej IRC niż stron internetowych, takich jak Stack Overflow, który jest znacznie rzadszy.

Myślę, że powodem tego jest to, że ludzie czują się lepiej, jeśli wiedzą, że konkretna osoba jest zainteresowana ich problemem i jest gotowa im pomóc. Zaczynają więc od stwierdzenia, że ​​mają problem, ale nie zagłębiają się w szczegóły, dopóki ktoś ich nie zapyta, ponieważ obawiają się, że inaczej nie uzyskają odpowiedzi.

Czasami (nie w przypadku błędów kompilatora) takie zachowanie ma sens. Jeśli mam duży skomplikowany problem, upewnię się, że ktoś najpierw słucha, zanim napisze długie wyjaśnienie, którego nikt nie przeczyta.

Ponieważ błędy / wyjątki kompilatora wymagają, abyś wiedział, co robisz źle, aby to naprawić. Są dla programistów, którzy przeoczają pewne rzeczy, a nie dla tych, którzy ich nie rozumieją.

Nie zawsze są one najbardziej oczywiste. Błąd typu „nieoczekiwany, jeśli” nie jest intuicyjny. „Ale jeśli powinno tam być” to odpowiedź nowicjusza. Bardziej doświadczony programista wie, że to oznacza, że ​​zapomniał średnika na poprzedniej linii.

Nie sądzę, że to tylko początkujący. Mam współpracowników z wieloletnim doświadczeniem, którzy wydają się patrzeć na numer linii tylko wtedy, gdy dostają błąd kompilatora, a następnie sami próbują znaleźć resztę (często próbując voodoo typu „dodajmy nawias” lub „podzielmy to” na dwie wypowiedzi ”).

Moje podejrzenie polega na tym, że tak naprawdę nie wynika to z głębokiego zrozumienia zasad języka, więc ogólny opis błędu nie ma większego znaczenia. expression must be a modifiable lvaluewydaje się dość bezużyteczną informacją, jeśli naprawdę nie wiesz, co to jest wartość .

Co takiego jest w komunikatach o błędach, które powodują, że ludzie początkowo zakładają, że są bezużyteczni i nie warto na nie zwracać uwagi?

Cóż, dla mnie była to młodzież wypełniona awarią oprogramowania Windows 95 z całkowicie nieprzeniknionymi komunikatami o błędach, które zwykle kończyły się około 150 liniami liczb szesnastkowych.

Ponownie przeżywam to samo doświadczenie za każdym razem, gdy otrzymuję ładny, tajemniczy ślad stosu Java, który będzie zawierał 40 wierszy bzdur kompilatora i błędów hibernacji, a wśród nich bardzo dobrze ukryte jest faktyczne odniesienie do tego, gdzie w mojej aplikacji jest błąd.

Powodem, dla którego ludzie ignorują komunikaty o błędach i ślady stosu, są często komunikaty o błędach i ślady stosu, które są nieproporcjonalnie skomplikowane w porównaniu ze złożonością problemu. Nie ma powodu, aby przepłukać 150 linii bzdur przez mój ekran, gdy brakuje mi średnika.

Uczę niektórych kursów na temat Linuksa dla Junior Sysadmins oraz programowania z PHP i Mysql. Większość studentów PHP zna błąd, ponieważ widzą brzydką wiadomość na ekranie. Ale wydaje się, że nie potrafią tego przeczytać. Zwykle przechodzę do ich ekranu, gdy mówią mi, że coś nie działa, czytam błąd na ekranie, każę im to przeczytać, podkreślając plik i wiersz zanotowany na błędzie i każę im tam zajrzeć. Poprawiają błąd, ale gdy pojawia się inny błąd, obowiązuje ta sama procedura ... westchnienie ...

W przypadku Linuksa czasami nawet nie zauważają błędu. Wprowadzają jakieś polecenie, niektóre linie pojawiają się na ekranie i kontynuują wykonywanie następnego polecenia. Kiedy niektóre polecenia później w końcu zauważą, że coś nie działa i podnoszę ręce, podchodzę, przewijam konsolę i wskazuję polecenie, które zakończyło się błędem z powodu złych parametrów lub cokolwiek innego. Ich twarz: niespodzianka. Tak więc łatwą częścią dla moich studentów Linuksa było powiadomienie ich o wystąpieniu błędu, przy użyciu pewnych modyfikacji monitu bash, aby wyróżnić się, gdy pojawi się błąd, taki jak ten . Teraz poproś, aby przeczytali komunikat o błędzie, gdy go zobaczą, to inna bitwa (taka sama jak w przypadku studentów PHP) ...

Uważam, że po prostu nie są przyzwyczajeni do myślenia o kodach błędów, a zanim dotrą do miejsca, w którym powinni je podać, mają już wrażenie, że w pełni wyjaśnili problem, a zatem jeszcze mniej prawdopodobne jest, że przestaną myśleć i zastanowią się, czy powinni podać dodatkowe informacje.

Zadanie pytania składa się z kilku etapów i są najbardziej logicznie ułożone w następującej kolejności:

1. musisz opisać, co robiłeś
2. musisz opisać, jak to robiłeś
3. musisz opisać, co się stało, gdy się nie udało (lub jak to się nie udało)
4. musisz złożyć raport pośmiertny

Raport pośmiertny zawiera komunikat o błędzie i jest na samym końcu. Zanim nowicjusze osiągną ten punkt, są już na skraju umysłowego wyzwania, jakim jest wyjaśnienie swojego problemu i istnieje większe prawdopodobieństwo, że coś przegapią (dla początkującego występuje problem z przeciążeniem informacyjnym). Co więcej, w tym momencie czują się już tak, jakby opisali wszystkie aspekty problemu i mają przeszłe nawyki, które uniemożliwiają im pamiętanie o kodach błędów: w końcu inne dziedziny życia nie mają kodów błędów, więc nie są przyzwyczajeni pomyśl o nich.

Może się również zdarzyć, że nawet jeśli pamiętają o kodach błędów, wydają się zbyt tajemnicze, aby mogły być faktycznie używane. Czym jest błąd 034982? Czy to naprawdę coś dla kogoś znaczy? I czy to naprawdę dodaje coś do tego szczegółowego opisu tego, co robiłem, jak to robiłem i jak to się nie udało? Niestety, ta informacja sama w sobie.

Ponieważ w większości języków większość komunikatów kompilatora / środowiska wykonawczego nie ma żadnego sensu. (Szczególnie C ++ i Java, patrzę na ciebie!) Poprawienie błędów jest raczej niskie na liście priorytetów projektanta języka. Dostarczenie rzeczy, które działają poprawnie do pracy jest zwykle większym priorytetem, a wiele czasu nie zawracają sobie głowy dopracowaniem drobnych szczegółów.

To jeden z powodów, dla których lubię pracować w Delphi. Cały język jest pełen dbałości o drobne szczegóły, w tym błędy. Komunikaty kompilatora mają sens. Komunikaty o błędach środowiska wykonawczego mają sens. Stosy śladów mają sens. Jest to jedna z rzeczy, która sprawia, że ​​jest to zdecydowanie najłatwiejszy język do debugowania, z jakim kiedykolwiek pracowałem.