Ci sono alcune regole per la gestione delle eccezioni che dovresti tenere a mente. Ma prima, è necessario ricordare che le eccezioni fanno parte dell'interfaccia esposte dal codice; documentali . Questo è particolarmente importante quando l'interfaccia è pubblica, ovviamente, ma è anche un'ottima idea nelle interfacce private.
Le eccezioni dovrebbero essere gestite solo nel punto in cui il codice può fare qualcosa di sensato con loro. L'opzione di gestione peggiore è di non fare nulla su di loro, che dovrebbe essere fatto solo quando è esattamente l'opzione corretta. (Quando ho una tale situazione nel mio codice, includo un commento in tal senso, quindi so che non mi preoccupo del corpo vuoto.)
La seconda opzione peggiore è lanciare un'eccezione non correlata senza l'originale allegato come causa. Il problema qui è che l'informazione all'interno dell'eccezione originale che consentirebbe la diagnosi del problema è persa; stai creando qualcosa con cui nessuno può fare nulla (oltre a lamentarsi del fatto che "non funziona", e sappiamo tutti quanto odiamo questi segnalazioni di bug).
Molto meglio sta registrando l'eccezione. Ciò consente a qualcuno di scoprire qual è il problema e risolverlo, ma è necessario registrare l'eccezione solo nel punto in cui sarebbe altrimenti persa o segnalata su una connessione esterna. Ciò non dipende dal fatto che la registrazione più frequente è un problema grave in quanto tale, ma piuttosto perché una registrazione eccessiva significa semplicemente che il log consuma più spazio senza contenere più informazioni. Una volta che hai registrato l'eccezione, puoi segnalare un précis all'utente / cliente con una buona coscienza (purché includa anche il tempo di generazione - o altro identificatore di correlazione) in quel rapporto così che la versione abbreviata può essere abbinata ai dettagli se necessario).
L'opzione migliore è, ovviamente, per gestire completamente l'eccezione, occupandosi della situazione di errore nella sua interezza. Se riesci a farlo, fallo assolutamente! Potrebbe anche significare che puoi evitare di dover registrare l'eccezione.
Un modo per gestire un'eccezione consiste nel generare un'altra eccezione che fornisce una descrizione di livello superiore del problema (ad es. " failed to initialize " invece di " index out of bounds "). Questo è un buon modello fintanto che non si perdono le informazioni sulla causa dell'eccezione; usa l'eccezione dettagliata per inizializzare il cause dell'eccezione di livello superiore o registra il dettaglio (come discusso sopra). La registrazione è più appropriata quando si sta per attraversare un confine tra processi, come una chiamata IPC, perché non è garantito che la classe di eccezione di basso livello sia presente sull'altra estremità della connessione. Mantenere una causa allegata è più appropriato quando si attraversa un confine interno.
Un altro pattern che vedi è catch-and-release:
try {
// ...
} catch (FooException e) {
throw e;
}
Questo è un anti-pattern a meno che tu abbia dei vincoli di tipo da altre clausole catch che significano che non puoi lasciar passare l'eccezione da solo. Quindi è solo una brutta caratteristica di Java.
Non c'è alcuna differenza tra le eccezioni controllate e quelle non selezionate, a parte il fatto che deve dichiarare eccezioni controllate che superano i limiti del metodo. È comunque consigliabile documentare le eccezioni non controllate (con il commento di @throws javadoc) se si sa che vengono deliberatamente generate dal codice. Non gettare deliberatamente java.lang.Error o le sue sottoclassi (a meno che tu non stia scrivendo un'implementazione JVM).
Opinione: un caso di errore imprevisto rappresenta sempre un bug nel codice. Le eccezioni controllate sono un modo per gestire questa minaccia e, laddove gli sviluppatori utilizzano deliberatamente eccezioni non controllate come metodo per evitare il problema di gestire i casi di errore, si accumula un sacco di debito tecnico che dovrai pulire un po 'di tempo se vuoi un codice robusto. La gestione errata degli errori non è professionale (e considerare la gestione degli errori è un buon modo per determinare quanto è buono un programmatore).