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

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 che hanno a disposizione è utile per capire qual è il problema. Se lo facessero, ci sarebbero maggiori possibilità di risolverlo da soli e non chiedere in proposito.

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 al primo avvio in questa professione sarà orribile rispetto al codice che scrivi oggi, le domande che porterai saranno terribili rispetto a come le chiedi oggi.

Quando inizi, è facile essere sopraffatti da tutte le informazioni che stai imparando e quando le cose non stanno andando a pianificare, è difficile sapere quali informazioni sono rilevanti e quali 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 dietro sia che le persone si sentano meglio se sanno che una persona in particolare è interessata al loro problema ed è disposta ad aiutarle. Quindi iniziano dicendo che hanno un problema, ma non entrano nei dettagli finché qualcuno non li chiede, perché temono che altrimenti non otterranno comunque una risposta.

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

Perché errori / eccezioni del compilatore richiedono di sapere cosa stai facendo male per risolverlo. Sono per i programmatori che trascurano le cose, non per le persone che non li capiscono.

Inoltre, non sono sempre le più ovvie. Un errore come "inaspettato se" non è così intuitivo. "Ma se dovrebbe essere lì" è la risposta di un principiante. Un programmatore più esperto sa che significa che ha dimenticato il punto e virgola sulla riga precedente .

Non penso che siano solo principianti. Ho collaboratori con anni di esperienza che sembrano guardare solo il numero di riga quando ottengono un errore del compilatore, quindi cercano di capire da soli il resto (spesso provando il voodoo come "aggiungiamo una parentesi" o "rompiamolo in due dichiarazioni ").

Il mio sospetto è che ciò derivi dal non avere una profonda comprensione delle regole del linguaggio, in modo che la descrizione generalmente densa dell'errore non abbia molto significato. expression must be a modifiable lvalue sembra un'informazione abbastanza inutile se davvero non sai cos'è lvalue .

What is it about error messages that makes people initially assume that they are useless and not worth paying any attention to?

Bene, per me, era un giovane pieno di crash del software Windows 95 con messaggi di errore completamente impenetrabili che in genere terminavano con circa 150 righe di esadecimali.

Riviviamo la stessa esperienza ogni volta che ottengo una bella traccia di stack Java criptica che conterrà 40 righe di errori di compilatore e di Hibernate, e nascosta molto bene tra loro è il vero riferimento a dove nella mia app si trova l'errore.

Il motivo per cui le persone ignorano i messaggi di errore e le tracce di stack sono spesso i messaggi di errore e le tracce di stack sono sproporzionatamente complicate rispetto alla complessità del problema. Non vi è alcun motivo per scaricare 150 righe di merda attraverso il mio schermo quando mi manca un punto e virgola.

Sto insegnando alcuni corsi su Linux per Junior Sysadmins e Programming 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 al loro schermo quando mi dicono che qualcosa non funziona, leggo l'errore sullo schermo, dico loro di leggerlo, enfatizzando il file e la linea annotati sull'errore e dicendogli di guardare lì. Corregge l'errore, ma quando viene visualizzato un altro errore, si applica la stessa procedura ... sospiro ...

Per il corso Linux, a volte non si notano nemmeno gli errori. Inseriscono un comando, alcune linee appaiono sullo schermo e continuano con il comando successivo. Quando alcuni comandi più tardi notano che qualcosa non funziona e alzano le mani, salgo, faccio scorrere la console verso l'alto e puntiamo a un comando che è uscito con un errore a causa di parametri non validi o altro. La loro faccia: sorpresa. Quindi la parte facile per i miei studenti linux era di farli notare quando si verifica un errore, usando alcune modifiche del prompt di bash per renderlo diverso quando appare un errore, come questo . Ora, falli leggere il messaggio di errore una volta che lo vedono, è una battaglia diversa (la stessa cosa con gli studenti PHP) ...

Credo che non siano abituati a pensare ai codici di errore, e quando raggiungono il luogo in cui dovrebbero darli, sentono già di aver spiegato a fondo il problema e sono quindi ancora meno propensi a fermarsi e pensare se dovrebbero fornire ulteriori informazioni.

Fare una domanda richiede alcune fasi e sono organizzate in modo più logico in questo ordine:

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

Il rapporto post mortem è dove verrà visualizzato il messaggio di errore, ed è proprio alla fine. Quando i neofiti 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 sentono già di aver descritto tutti gli aspetti del problema e hanno abitudini passate che impediscono loro di ricordare i codici di errore: dopotutto, altri campi della vita non hanno codici di errore, quindi non sono abituati a pensaci.

Può anche darsi che anche se si ricordano dei codici di errore, sembrano troppo criptici per essere effettivamente utilizzati. Che cos'è l'errore 034982? Questo significa davvero qualcosa per qualcuno? E aggiunge davvero qualcosa alla descrizione dettagliata di ciò che stavo facendo, di come lo stavo facendo e di come ha fallito? Sicuramente questa informazione è valida.

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

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