Quanto devono essere dettagliati i messaggi di errore?

Question

Mi chiedevo quale fosse il consenso generale sui messaggi di errore. Quanto devono essere dettagliati?

Ho lavorato su progetti in cui era presente un messaggio di errore diverso per l'immissione di un numero troppo grande, troppo piccolo, con un decimale, una stringa, ecc. È stato molto carino per l'utente poiché sapevano esattamente dove le cose sono andate male, ma il codice di gestione degli errori ha iniziato a competere con le dimensioni della logica di business effettiva e ha iniziato a sviluppare alcuni dei suoi bug.

Dall'altro lato ho lavorato a un progetto in cui si otterrebbero errori molto generici come

  

COMPILE FAILED REASON 3

Che inutile dire che era quasi del tutto inutile poiché la ragione 3 si è rivelata un errore di collegamento.

Quindi dov'è la via di mezzo? Come faccio a sapere se ho aggiunto messaggi di errore sufficientemente descrittivi? Come faccio a sapere se l'utente sarà in grado di capire dove hanno sbagliato?

Answer 1

Esistono due possibili destinatari per un messaggio di errore, l'utente e lo sviluppatore.

Uno dovrebbe generalmente avere il messaggio come target dell'utente.

o qual è la causa del problema.
 o perché il programma non può aggirare il problema
 o cosa l'utente può fare per aggirare il problema.
 o come segnalare il problema.

Se il problema deve essere segnalato, il rapporto dovrebbe includere quante più informazioni possibili sul contesto del programma.

o nome del modulo
 o nome della funzione
 o numero di riga
 o variabili di interesse nell'area generale del problema
 o forse anche una discarica principale.

Scegli come target il pubblico corretto.

Answer 2

Dovresti comunicare cosa è successo e quali sono le opzioni dell'utente, nel minor numero di parole possibile. Più è lungo il messaggio di errore, meno è probabile che l'utente lo legga. Allo stesso modo, brevi messaggi di errore sono criptici e inutili. C'è un punto debole in termini di lunghezza ed è diverso per ogni situazione.

Troppo breve:

  

Input non valido.

Troppo lungo:

  

Inserire un indirizzo IP correttamente formattato, ad esempio 192.168.0.1. Un indirizzo IP è un numero utilizzato per identificare il tuo computer su una rete.

Giusto:

  

Inserisci un indirizzo IP valido.

Per quanto riguarda il bloat di codice, se un piccolo codice aggiuntivo impedirà a un utente di chiamare il supporto o ottenere frustra, allora è un buon investimento.

Answer 3

Esistono due tipi di messaggi di errore: quelli che verranno visualizzati dall'utente e quelli che verranno visualizzati dal programmatore.

" Come faccio a sapere se l'utente sarà in grado di capire dove hanno sbagliato? " Suppongo che questi messaggi vengano visualizzati solo dall'utente, e non molto tecnici, e COMPILE FAILED REASON 3 non è un tipico messaggio di errore dell'utente finale. È qualcosa che il programmatore vedrà (l'utente di solito non compila cose).

Quindi, se è l'utente che lo vedrà:

1. Fornisci un breve "Questo è un messaggio di errore" ("Ops! Qualcosa è andato storto!", ecc.)
2. Fornisci una piccola descrizione generica dell'errore (" Il sito a cui stai tentando di connetterti sembra non essere disponibile " / " Non sembri avere autorizzazioni sufficienti per eseguire l'attività XYZ " / etc.)
3. Aggiungi un " Dettagli > > " nel caso in cui l'utente capisca bene i computer, comprese informazioni dettagliate (traccia dello stack delle eccezioni, codice di errore, ecc.)

Infine, fornisci alcuni comandi semplici e comprensibili per l'utente (" Riprova " ;, " Annulla " ;, ecc.)

Answer 4

La vera domanda sui messaggi di errore è se dovrebbero anche essere visualizzati. Molti messaggi di errore vengono presentati a un utente, ma NON È POSSIBILE correggerli.

Finché esiste un modo per correggere l'errore, fornire all'utente informazioni sufficienti che consentano loro di correggerlo da soli. Se non sono in grado di correggerlo da soli, c'è qualche motivo per dire loro il motivo tecnico dell'incidente? Non basta registrarlo in un file per la risoluzione dei problemi in seguito.

Answer 5

Tanto dettagliati quanto devono essere;)

So che suona come una risposta intelligente ma molto dipende dal tuo pubblico di destinazione e dal tipo di errore. Per errori causati da una voce utente non valida, è possibile mostrare loro ciò che costituisce una voce valida. Per errori che l'utente non può controllare, un generico "ci stiamo lavorando" potrebbe essere un messaggio di tipo.

Concordo anche con i commenti di Jon B sulla lunghezza.

Answer 6

I messaggi di errore devono essere dettagliati, ma chiari. Ciò può essere ottenuto combinando messaggi di errore da più livelli:

Failed to save the image
Permission denied: /foo.jpg

Qui abbiamo due livelli. Ce ne possono essere di più. Prima raccontiamo il quadro generale e poi raccontiamo i dettagli. L'ordine è tale che prima abbiamo capito la parte dalla maggior parte e poi la parte che meno persone capiscono, ma entrambe possono ancora essere visibili.

Inoltre potrebbe esserci un suggerimento per la correzione.

Answer 7

Vorrei sbagliare sul lato di maggiori dettagli, ma penso che tu abbia risposto alla tua domanda. Per evitare il rigonfiamento del codice, fornire informazioni utili nel messaggio di codice / errore, ma è possibile fornire maggiori dettagli nella documentazione, magari con file di aiuto o FAQ.

avere troppe poche informazioni è peggio secondo me.

Se stai usando una lingua con ricca introspezione o altre capacità, sarebbe utile un registro con la sua linea che non ha superato un controllo. L'utente può quindi inoltrare al supporto tecnico o altrimenti ottenere informazioni dettagliate e questo non è un eccesso di codice aggiuntivo, ma l'utilizzo del proprio codice per fornire informazioni.