Quale stile usi per i messaggi di eccezione? [chiuso]

Question

Nello scrivere il codice che genera l'eccezione, ho chiesto di qui , sono arrivato alla fine del mio messaggio e mi sono fermato alla punteggiatura. Mi sono reso conto che quasi ogni messaggio di eccezione che abbia mai lanciato probabilmente ha un! da qualche parte.

throw new InvalidOperationException("I'm not configured correctly!");
throw new ArgumentNullException("You passed a null!");
throw new StupidUserException("You can't divide by 0!  What the hell were you THINKING???  DUMMY!!!!!");

Che tono hai quando scrivi i messaggi di eccezione? Quando si esaminano i registri, trovi che un certo stile di messaggio aiuta davvero più di un altro?

Answer 1

Un tono di conversazione nei messaggi di sistema rende il software poco professionale e sciatto. I punti esclamativi, gli insulti e il gergo non hanno davvero un posto nei messaggi delle eccezioni.

Inoltre, tendo a utilizzare stili diversi in Java per le eccezioni di runtime e le eccezioni verificate, poiché le eccezioni di runtime sono indirizzate al programmatore che ha commesso l'errore. Dal momento che le eccezioni di runtime potrebbero essere visualizzate per gli utenti finali, continuo a "mantenerlo pulito", " ma possono essere un po 'più concisi e criptici. I messaggi di eccezione controllati dovrebbero essere più utili, dal momento che l'utente può risolvere il problema se lo descrivi (ad esempio, file non trovato, disco pieno, nessuna route verso l'host, ecc.).

Una cosa utile, in assenza di un campo specifico sull'eccezione per le informazioni, sono i dati offensivi:

throw new IndexOutOfBoundsException("offset < 0: " + off);

Answer 2

Sii solo un dato di fatto. Includi tutte le informazioni di cui potresti avere bisogno durante il debug, ma niente di più.

L'unica volta in cui includo un punto esclamativo in un messaggio di eccezione è se indica che è successo qualcosa di veramente, davvero bizzarro. La maggior parte degli errori non sono davvero bizzarri, solo il prodotto di un ambiente errato, errore dell'utente o un semplice errore di programmazione.

Answer 3

Provo a rispecchiare il tono, la grammatica e lo stile di punteggiatura del framework su cui sto codificando. Non si sa mai quando uno di questi messaggi potrebbe effettivamente essere visualizzato davanti a un client o un utente, quindi tengo tutto professionale, non giudicante e abbastanza specifico per la risoluzione dei problemi - senza essere così specifico da dare via eventuali problemi di sicurezza nel codice.

Evito i punti esclamativi in ??tutte le stringhe (UI ed eccezione) come la peste, tranne (occasionalmente) nei test delle mie unità.

Answer 4

Assumersi la responsabilità, anche quando è stata davvero colpa dell'utente, è l'opzione migliore che abbia mai visto.

Le cose lungo le righe di " Non riesco a trovare il file desiderato, controlleresti di vederlo correttamente? " o " Qualcosa è andato storto. Non so cosa, ma l'unico modo in cui posso sistemarmi è fermarmi. Per favore, riavviami. & Quot;

Answer 5

Informazioni concise, dettagliate e poco ridondanti (ad esempio ArgumentNullException implicava ovviamente un valore nullo).

Ma ecco il migliore che ho letto per un po ', prima risposta a questo .

Answer 6

Non userei troppo i punti esclamativi. Esprimono troppo, pensa al fatto che "Nessun disco nell'unità!" può essere letto come " Nessun disco nell'unità, utente pazzo. " ;)

Penso che sia saggio lanciare eccezioni che contengono testo internazionalizzato. Non sai mai chi utilizzerà il tuo codice, prendi la tua eccezione e mostra il testo all'utente. Quindi sarebbe:

throw new MagicalException(getText("magical.exception.text"));

Consiglio anche di racchiudere l'eccezione sottostante (se ne hai una) quando la lanci. Aiuta davvero il debug.

Non pensare che le eccezioni di runtime non vengano visualizzate dall'utente. Se stai accedendo a un appender di file, alcuni utenti curiosi potrebbero semplicemente aprire il registro e sbirciare tra i tuoi segreti sporchi .

Answer 7

Trovo che i messaggi più utili forniscano:

• Un formato coerente che semplifica la comprensione di ciò che ti stanno dicendo.
• Un timestamp, in modo da poter avere un'idea delle dinamiche del tuo programma.
• Un sommario sintetico dell'errore. Se fornisci supporto tecnico, aggiungi un codice di errore per una rapida identificazione.
• Una spiegazione di cosa è andato storto, distinguendo tra un input utente non valido e un errore di codifica.
• Informazioni dettagliate , inclusa la riga di codice o valori coinvolti.

E soprattutto:

• Dicono all'utente come risolvere il problema.

Esempio:

Error 203 (Timeout) in commit.c line 42:
Unable to save salary data for user 'Linus' to database at '10.10.1.21'
after 1500ms.  Verify database address and login credentials.

Una delle lezioni più difficili da imparare è che i tuoi utenti sono molto meno interessati agli interni del tuo codice di quanto non lo siano nel portare a termine il proprio lavoro. Rendi il più semplice possibile per loro il loro lavoro e hai aggiunto un valore straordinario al tuo software.

Answer 8

Tendo a elaborare i miei messaggi di eccezione nell'eccezione stessa. Per esempio. un file_not_found dovrebbe indicare "file non trovato". Dati specifici dovrebbero essere inclusi solo se l'utente non è in grado di capirlo; in questo caso, l'utente conosce il nome del file, quindi non aggiungo tali dati. Se necessario, la formattazione può essere eseguita da qualsiasi output delle informazioni, quindi cerco di renderli quanto più amichevoli alla riformattazione possibile.

Answer 9

Gentile, conciso, semplice, specifico. Spesso è utile includere i valori di stato nel messaggio.