Sì

I messaggi di errore (quando necessario) devono essere presentati all'utente.

What rules or advice should you have about what should be in them?

Presenta un errore all'utente quando:

1. Cosa devono sapere. Non includere errori che non capiranno. "Connessione SQL non riuscita" non è un buon errore. "Si è verificato un errore durante il salvataggio dell'appuntamento. " è molto meglio.

2. Possono ripararlo. "Non hai inserito una data per l'appuntamento." è un errore risolvibile.

3. Si aspettano che succeda qualcosa. Non fallire silenziosamente quando si aspettano qualcosa. Riconoscere l'azione dell'utente come minimo e, al massimo, fornire un errore appropriato.

I messaggi di errore dovrebbero essere presentati all'utente se:

• L'utente ha avviato la condizione di errore (ad esempio, "you did not include a password on the input form" )
• L'utente può fare qualcosa per la condizione di errore (ad esempio, "there is no network connection" )
• Si è verificato un errore critico che l'applicazione non è in grado di ripristinare (ad esempio, "the database is corrupt" )

Penso che sia piuttosto importante mostrare un qualche tipo di messaggio a livello utente quando le eccezioni aumentano, in questo modo hanno qualcosa da segnalare a un supervisore, il team di sviluppo potrebbe avere più informazioni e il bug tracking potrebbe essere fatto molto più velocemente .

Il dettaglio del messaggio dovrebbe dipendere dall'ambiente in cui è in esecuzione l'app, da totalmente dettagliato in dev env a "Si è verificato un problema durante il salvataggio di un profilo, contatta il tuo supervisore" su un prod env.

Dovresti presentare messaggi di errore all'utente se lui / lei può fare qualcosa al riguardo . O permettendo l'invio di una segnalazione di bug prima di uscire, o decidendo la strada da percorrere dopo un tipo specifico di errore, uno che ha diverse risoluzioni possibili che l'utente conosce meglio il contesto.

Non interrompere l'esperienza utente se è possibile / finché non è necessario.

Gli errori dovrebbero essere presentati all'utente quando lui / lei può fare qualcosa, insieme con la linea d'azione suggerita anche se deve essere "chiama questo numero" o "clicca su questo link per segnalare il problema".

Non presentare mai all'utente un errore privo di significato o che non offre una linea di condotta.

Mi piace essere in grado di dire agli utenti se c'è un problema con il loro ambiente o configurazione che sta per fermare il funzionamento del software e se possibile suggerire come affrontarlo. Non puoi sempre sapere perché fallirai, ma i problemi ambientali sono una delle cose più comuni che incontri con i PC.

Gli utenti dovrebbero sempre sapere in qualche modo se c'è un problema che significa che non possono svolgere l'attività che stanno cercando di fare. Potresti non dirlo nello stesso modo in cui lo faresti per tuo uso personale, ma devi far loro sapere che qualcosa è successo. Idealmente, vuoi offrire alla struttura la possibilità di notificare automaticamente allo sviluppatore che si è verificato anche il problema.

La terza situazione è se hanno commesso un errore - hanno lasciato un campo vuoto, hanno inserito il formato errato dei dati in un campo e così via - che possono correggersi da soli.

I messaggi di errore devono sempre chiarire cosa è successo e cosa l'utente può fare per ordinarlo, o cosa devono fare per sfruttarlo al meglio.

Sì, gli errori dovrebbero essere segnalati. Considerare la situazione in cui l'utente immette la password errata ed è stato in grado di connettersi. Immagina cosa succede se l'applicazione invece di dare un errore, "Password o nome utente errati" torna semplicemente alla schermata di richiesta della password originale. L'utente si confonderà sicuramente dicendo "Huh, cosa è successo?".
Segnala ogni possibile errore che può verificarsi e che l'utente può capire. Pensa anche a quali informazioni dovrebbero essere visualizzate. Pensa al supporto. Se l'utente dopo aver ricevuto l'errore, torna a chiedere perché l'errore, quindi il supporto dovrebbe essere in grado di rispondere. Per questo ci dovrebbero essere informazioni sufficienti nell'errore. Queste informazioni non devono essere mostrate all'utente, ma devono essere da qualche parte nei registri.

Dovresti sempre presentare un problema a un utente in parole facilmente comprensibili basate sulle informazioni fornite dall'architettura sottostante.

"Impossibile salvare il file in questa posizione. Devi salvarlo in un'altra posizione".

Devi anche consentire all'utente di accedere ai messaggi di errore completi e inoltrarli al team di sviluppo, ma non farlo in anticipo. Questo può essere molto utile in una situazione di supporto telefonico.

Il mio consiglio, in termini di codice, è di mai ingoiare errori / eccezioni e di non rilevare mai eccezioni generali. Cattura solo quelli specifici che sai sono possibili (ad esempio, errori di matrice "fuori dai limiti") e gestiscili di conseguenza, dando all'utente qualche tipo di feedback come per @ risposta di Josh K .

Tuttavia, ci sono momenti in cui è probabilmente meglio ingurgitare errori. Qualcosa di stupido come un utente apre un file utilizzato dalla tua app e interrompe prematuramente il programma, causando un qualche tipo di errore nella gestione dei file - la tua applicazione si sta chiudendo, non offre alcun vantaggio per affrontarla. In questo caso, non dovresti semplicemente ignorarlo, basta scaricare il problema in un log degli errori e se l'utente ha un problema, puoi fare riferimento a questo.

Questo è anche un altro punto: registra gli errori dell'applicazione con un log degli errori. Abbastanza semplice da fare e potrebbe salvarti dozzine di mal di testa in futuro. Prendi le dovute precauzioni per assicurarti che non raggiungano i 20 GB di dimensioni.