Ci sono alcune regole per la gestione delle eccezioni che dovresti tenere a mente. Ma prima, devi ricordare che le eccezioni fanno parte dell'interfaccia esposta dal codice; documentarli . Ciò è particolarmente importante quando l'interfaccia è pubblica, ovviamente, ma è un'ottima idea anche nelle interfacce private.
Le eccezioni dovrebbero essere gestite solo nel punto in cui il codice può fare qualcosa di ragionevole con loro. L'opzione di gestione peggiore è di non fare nulla al riguardo, cosa che dovrebbe essere fatta solo quando questa è esattamente l'opzione corretta. (Quando ho una situazione del genere nel mio codice, includo un commento in tal senso, quindi so di non preoccuparmi del corpo vuoto.)
La seconda opzione peggiore è lanciare un'eccezione non correlata senza l'originale allegato come causa. Il problema qui è che le informazioni all'interno dell'eccezione originale che consentirebbero la diagnosi del problema vanno perse; stai creando qualcosa con cui nessuno può fare nulla (oltre a lamentarsi del fatto che "non funziona" e sappiamo tutti come odiamo le segnalazioni di bug).
Molto meglio è la registrazione dell'eccezione. Ciò consente a qualcuno di scoprire qual è il problema e risolverlo, ma è necessario registrare l'eccezione solo nel punto in cui verrebbe altrimenti perso o segnalato su una connessione esterna. Ciò non è dovuto al fatto che la registrazione più frequente è un grave problema in quanto tale, ma piuttosto perché una registrazione eccessiva significa che il registro consuma solo più spazio senza contenere più informazioni. Una volta effettuato l'accesso l'eccezione, è possibile segnalare un précis per l'utente / cliente con una buona coscienza (a patto che si includa anche l'ora di creazione - o altro identificativo di correlazione - in tale relazione in modo che la versione corta può essere abbinato con i dettagli se necessario).
L'opzione migliore è, ovviamente, gestire completamente l'eccezione, affrontando la situazione di errore nella sua interezza. Se riesci a farlo, fallo sicuramente! Potrebbe anche significare che è possibile evitare di registrare l'eccezione.
Un modo per gestire un'eccezione è di lanciare un'altra eccezione che fornisce una descrizione di livello superiore del problema (ad esempio, " failed to initialize" anziché " index out of bounds"). Questo è un buon modello fino a quando non perdi le informazioni sulla causa dell'eccezione; utilizzare l'eccezione dettagliata per inizializzare l' causeeccezione di livello superiore o registrare i dettagli (come discusso sopra). La registrazione è più appropriata quando si sta per attraversare un confine tra processi, come una chiamata IPC, perché non esiste alcuna garanzia che la classe di eccezione di basso livello sarà presente all'altra estremità della connessione. Conservare come causa associata è più appropriato quando si attraversa un confine interno.
Un altro modello che vedi è catch-and-release:
try {
// ...
} catch (FooException e) {
throw e;
}
Questo è un anti-pattern a meno che tu non abbia vincoli di tipo da altre catchclausole che significano che non puoi lasciare che l'eccezione passi da sola. Quindi è solo una brutta caratteristica di Java.
Non vi è alcuna reale differenza tra le eccezioni verificate e quelle non selezionate oltre al fatto che è necessario dichiarare eccezioni controllate che attraversano i limiti del metodo. È comunque una buona idea documentare le eccezioni non controllate (con il @throwscommento javadoc) se sai che sono state lanciate deliberatamente dal tuo codice. Non gettare deliberatamente java.lang.Erroro le sue sottoclassi (a meno che non si stia scrivendo un'implementazione JVM).
Opinione: Un caso di errore imprevisto rappresenta sempre un bug nel codice. Le eccezioni verificate sono un modo per gestire questa minaccia e dove gli sviluppatori utilizzano deliberatamente eccezioni non controllate come modo per evitare il problema di gestire i casi di errore, si stanno accumulando molti debiti tecnici che si dovranno ripulire un po 'di tempo se vuoi un codice robusto. La gestione degli errori sciatta non è professionale (e guardare la gestione degli errori è un buon modo per determinare quanto sia realmente bravo un programmatore).