Perché i nuovi programmatori sembrano ignorare i messaggi di errore del compilatore / i messaggi di eccezione di runtime? [chiuso]

Penso che l'abbiamo visto tutti. I principianti fanno domande su Stack Overflow che seguono lo schema di base ...

Sto provando a farlo (descrizione molto vaga dell'obiettivo) ma non funziona / Ottengo un errore / un'eccezione. Per favore aiuto!

Non è strano che così tanti di loro sembrino inutili incollare il messaggio di errore?

Mi chiedo quale sia la psicologia di questo. Di cosa si tratta nei messaggi di errore che inducono inizialmente le persone a considerare inutili e alle quali non vale la pena prestare attenzione?

La risposta che sto cercando non è "non capiscono il messaggio di errore". Questo non spiega perché non prenderebbero in considerazione l'idea di dirlo a qualcun altro che potrebbe capirlo.

Penso che il vero motivo sia che gli utenti di computer ordinari, anche se dovrebbero diventare programmatori, sono condizionati a credere di non poter fare nulla per gli errori. Pensaci. Cosa fanno i tipi non programmatori quando incontrano un messaggio di errore criptico *? Potrebbero leggerlo, ma nove volte su dieci lo licenzieranno e riproveranno. Solo se fallisce costantemente lo guarderanno.

Pertanto, quando iniziano a imparare a programmare, le persone non si rendono immediatamente conto che l'errore che stanno ricevendo contiene informazioni utili su come risolverlo; e sì, anche se gli errori del compilatore possono essere quasi illeggibili anche per il professionista addestrato (ti sto guardando, metaprogrammazione del modello C ++), almeno forniscono un punto di partenza generale e una volta che hai visto lo stesso errore un paio di volte , saprai sempre cosa hai fatto per causarlo.

* Onestamente, però, la maggior parte dei messaggi di errore si rivolge a Joe Average come "Errore X2412: impossibile stabilire un dongledash interpiattaforma frobnicatorio: verificare le impostazioni di bandersnatch o contattare l'amministratore di sistema."

Penso che se è un vero principiante, ci sono buone probabilità che non sappiano che c'è un messaggio di errore. Sanno solo che non funziona e che c'è un errore. Ad esempio in Visual Studio potrebbero non vedere quella parte dello schermo.

Fondamentalmente non sanno quale parte delle informazioni disponibili è utile per capire quale sia il problema. Se lo facessero, ci sarebbero maggiori possibilità che possano risolverlo da soli e non chiederlo in primo luogo.

Penso che porre domande e risolvere i problemi sia un'abilità che deve essere appresa e, per gli sviluppatori professionisti, è un'abilità importante che semplicemente non viene insegnata abbastanza spesso.

Proprio come il codice che scrivi quando inizi per la prima volta in questa professione sarà orribile rispetto al codice che scrivi oggi, le domande che poni saranno terribili rispetto al modo in cui le fai oggi.

Quando inizi, è facile essere sopraffatto da tutte le informazioni che stai imparando e quando le cose non pianificheranno, è difficile sapere quali informazioni sono rilevanti e cosa no. Questa è una grande parte del motivo per cui i principianti non possono risolvere il problema da soli in primo luogo!

Questo vale più per IRC che per i siti Web online come Stack Overflow, che è molto più raro.

Penso che il ragionamento alla base sia che le persone si sentano meglio se sanno che una persona in particolare è interessata al loro problema ed è disposta ad aiutarli. Quindi iniziano dicendo che hanno un problema, ma non entrano nei dettagli fino a quando qualcuno non glielo chiede, perché hanno paura che altrimenti non otterranno comunque una risposta.

A volte (non nel caso di errori del compilatore) questo comportamento ha effettivamente senso. Se avrò un grosso problema complicato, mi assicurerò che qualcuno ascolti prima di scrivere una lunga spiegazione che nessuno leggerà.

Perché errori / eccezioni del compilatore richiedono che tu sappia cosa stai facendo di sbagliato per risolverlo. Sono per programmatori che trascurano cose, non per persone che non le capiscono.

Inoltre, non sono sempre i più ovvi. Un errore come "imprevisto se" non è così intuitivo. "Ma che se dovesse esserci" è la risposta di un principiante. Un programmatore più esperto sa che ciò significa che ha dimenticato il punto e virgola sulla riga precedente .

Non penso siano solo i neofiti. Ho collaboratori con anni di esperienza che sembrano guardare il numero di riga solo quando ricevono un errore del compilatore, quindi provano a capire il resto da soli (spesso provando il voodoo come "aggiungiamo parentesi" o "rompiamo questo in due affermazioni ").

Il mio sospetto è che questo deriva dal fatto di non avere una profonda comprensione delle regole della lingua, quindi la descrizione generalmente densa dell'errore non ha molto significato. expression must be a modifiable lvaluesembra un'informazione piuttosto inutile se davvero non sai cos'è un lvalue .

Di cosa si tratta nei messaggi di errore che inducono inizialmente le persone a considerare inutili e alle quali non vale la pena prestare attenzione?

Bene, per me, è stata una gioventù piena di crash del software Windows 95 con messaggi di errore completamente impenetrabili che di solito terminavano con circa 150 righe di valori esadecimali.

Rivivo la stessa esperienza ogni volta che ottengo una bella traccia criptica dello stack Java che conterrà 40 righe di errori di compilazione ed errori di ibernazione, e nascosti molto bene tra loro è l'effettivo riferimento a dove si trova l'errore nella mia app.

Il motivo per cui le persone ignorano i messaggi di errore e le tracce dello stack è spesso che i messaggi di errore e le tracce dello stack sono sproporzionatamente complicati rispetto alla complessità del problema. Non c'è motivo di scaricare 150 linee di schifezze attraverso il mio schermo quando mi manca un punto e virgola.

Sto insegnando alcuni corsi su Linux per Junior Sysadmins e programmando con PHP e Mysql. La maggior parte degli studenti su PHP sa che c'è un errore perché vedono il brutto messaggio sullo schermo. Ma sembrano incapaci di leggerlo. Di solito vado sul loro schermo quando mi dicono che qualcosa non funziona, leggo l'errore sullo schermo, dico loro di leggerlo, sottolineando il file e la riga annotati sull'errore e dico loro di guardare lì. Correggono l'errore, ma quando appare un altro errore, si applica la stessa procedura ... sigh ...

Per il corso Linux, a volte non notano nemmeno l'errore. Immettono alcuni comandi, alcune linee appaiono sullo schermo e continuano con il comando successivo. Quando in seguito alcuni comandi si accorgono che qualcosa non funziona e alzo la mano, mi alzo, scorro la console e indico a un comando che è uscito con un errore a causa di parametri errati o altro. La loro faccia: sorpresa. Quindi la parte facile per i miei studenti di Linux è stata farli notare quando si verifica un errore, usando alcune modifiche del prompt di bash per renderlo diverso quando appare un errore, come questo . Ora, fai in modo che leggano il messaggio di errore una volta che lo vedono, è una battaglia diversa (la stessa degli studenti PHP) ...

Credo che non siano abituati a pensare ai codici di errore e, quando raggiungono il posto in cui dovrebbero fornirli, hanno già la sensazione di aver spiegato completamente il problema e quindi hanno anche meno probabilità di fermarsi e pensare se dovrebbero fornire ulteriori informazioni.

Fare una domanda comporta alcune fasi e sono logicamente disposti in questo ordine:

1. devi descrivere cosa stavi facendo
2. devi descrivere come lo stavi facendo
3. devi descrivere cosa è successo quando ha fallito (o come è fallito)
4. è necessario fornire il rapporto post mortem

Il rapporto post mortem è dove si trova il messaggio di errore ed è alla fine. Quando i principianti raggiungono questo punto, sono alla fine della sfida mentale di spiegare il loro problema e hanno maggiori probabilità di perdere qualcosa (per un principiante, c'è un problema di sovraccarico di informazioni). Inoltre, a questo punto hanno già la sensazione di aver descritto tutti gli aspetti del problema e hanno abitudini passate che impediscono loro di ricordare i codici di errore: dopo tutto, altri campi della vita non hanno codici di errore, quindi non sono abituati a pensaci.

Può anche darsi che, anche se ricordano i codici di errore, sembrano troppo criptici per essere effettivamente utili. Che cos'è l'errore 034982? Significa davvero qualcosa per nessuno? E aggiunge davvero qualcosa a quella descrizione dettagliata di quello che stavo facendo, di come lo stavo facendo e di come è fallito? Sicuramente questa informazione si distingue da sola.

Perché per la maggior parte delle lingue, la maggior parte dei messaggi di compilatore / runtime non ha alcun senso. (Soprattutto C ++ e Java, ti sto guardando!) Fare gli errori giusti tende ad essere piuttosto basso nella lista delle priorità di un progettista di lingue. Fare in modo che le cose che funzionano bene funzionino correttamente è di solito una priorità più grande, e molto tempo non si preoccupano di lucidare i piccoli dettagli.

Questo è uno dei motivi per cui mi piace lavorare in Delphi. L'intera lingua è piena di attenzione ai piccoli dettagli, inclusi gli errori. I messaggi del compilatore hanno un senso. I messaggi di errore di runtime hanno senso. Le tracce dello stack hanno un senso. È una delle cose che lo rende di gran lunga il linguaggio più semplice per il debug con cui abbia mai lavorato.