È solo una buona pratica catturare un'eccezione specifica se può effettivamente essere gestita dal blocco catch.
Molto spesso, i programmatori presumono che l'errore possa essere gestito del tutto, vicino al punto in cui si verifica. Questo è spesso sbagliato. Per capire perché, dobbiamo esplorare cosa significa "gestione".
Il tuo secondo frammento:
try {
// code implementation
} catch (IOException | SQLException | NullPointerException ex ) {
// handle exception
}
implica che potrebbero esserci alcune azioni utili che potrebbero gestire l'eccezione rilevata. Ma spesso non è così. Come è stato notato nei commenti, le prestazioni sono irrilevanti se il codice fornisce risultati errati.
L'unica cosa che puoi fare con NullPointerException è registrare tutto ciò che è importante per il debugging e la morte; ogni ulteriore tentativo di continuare ha un'alta probabilità di stomping sull'heap e di rompere altre cose a valle. Questa eccezione deriva da un difetto del software e non può essere gestita correttamente.
Suppongo che code implementation consista nella lettura di un istream. La gestione di una IOException potrebbe essere semplice come rileggere la parte che ha generato l'eccezione (se causata da una chiamata di sistema interrotta) ma questo è il caso raro e un'eccezione troppo generalizzata. Se l'errore è FileNotFoundException, hai un difetto upstream che non può essere gestito in questo contesto. Chi potrebbe gestirlo? Il codice che ha creato l'istream avrebbe potuto gestire l'eccezione se c'era un file alternativo ragionevole da aprire, ma lo snippet di esempio dovrebbe essere privo delle informazioni. Se stessimo tentando di aprire un file senza alternative ragionevoli, tutto ciò che l'apri può fare è lanciare un'eccezione stessa.
Perché? Perché c'è un contratto tra il codice di apertura e il suo chiamante che dice "dammi un percorso, e lo aprirò per te e ti darò un istream". Su FileNotFoundException, il codice di apertura non è riuscito a soddisfare il suo contratto e indurrà errori nel chiamante e in altri luoghi in cui si accede all'istream. È questa violazione del contratto è il caso più strong per le eccezioni.
Supponiamo che FileNotFoundException sia stato lanciato in un programma a esecuzione prolungata come un editor. Sarebbe scortese che l'applicazione si arresti in modo anomalo solo perché hai digitato un nome di file. In questo caso, l'eccezione dovrebbe essere consentita per propagarsi fino al ciclo principale che effettivamente può gestirlo: cioè informando l'utente "file non trovato" dando così all'utente la possibilità di provare un altro nome file.
Quando un'eccezione implica un errore del contratto, tale eccezione deve propagarsi verso l'alto fino a quando non vi è un codice che può effettivamente correggere l'errore del contratto. Se non è possibile correggere l'errore (come in cat not_a_file ), il meglio che puoi fare è stampare un messaggio di errore significativo e (come in cat not_a_file a_file ) saltare not_a_file .