Non è una buona pratica gestire le eccezioni di runtime nel codice?

Dipende.

Ad esempio, Integer#parseInt genera NumberFormatException (che è un RTE) se la stringa fornita non può essere analizzata. Ma sicuramente non vuoi che la tua app si arresti in modo anomalo solo perché l'utente ha scritto "x" in un campo di testo che era per interi? E come fai a sapere se la stringa può essere analizzata, a meno che non provi ad analizzarla prima? Quindi in questo caso, l'RTE è solo un segnale di errore che dovrebbe causare qualche tipo di messaggio di errore. Si potrebbe sostenere che dovrebbe essere un'eccezione controllata, ma cosa si può fare? Non lo è.

NullPointerExceptions è solitamente il segno di un assegno nullo mancante. Quindi, invece di prenderlo in questo modo, dovresti aggiungere il controllo nullo appropriato per essere sicuro di non lanciare l'eccezione.

Ma a volte, è appropriato gestire RunTimeExceptions. Ad esempio, quando non è possibile modificare il codice per aggiungere il controllo null nella posizione appropriata o quando l'eccezione è diversa da una NullPointerException.

Il tuo esempio di gestione delle eccezioni è terribile. In questo modo, si perde la traccia dello stack e le informazioni precise sul problema. E in realtà non lo stai risolvendo perché probabilmente innescherai un'altra NullPointerException in un posto diverso e otterrai informazioni fuorvianti su cosa è successo e su come risolverlo.

Gestisco le eccezioni attese dove mi aspetto. (Come gli errori di lettura / scrittura DB). Eccezioni impreviste Mi ribellano. Da qualche altra parte potrebbe aspettarsi l'eccezione e avere la logica per farlo.

Le eccezioni dovrebbero essere proprio questo ... eccezioni. La migliore pratica quando si usano le eccezioni è usarle per coprire la situazione in cui accade qualcosa di contrario a ciò che ci si aspetta che accada. L'esempio classico è FileNotFoundException che viene generato quando un file non è semplicemente lì. Se stai verificando l'esistenza del file, allora usi File.exists () dal momento che stai semplicemente spingendo con uno stick da 10 piedi per vedere se colpisci qualcosa.

Potresti ottenere tecnicamente gli stessi risultati circondandolo in un try catch e usando il file come se esistesse, ma A) le eccezioni sono generalmente costose in termini di risorse e B) i programmatori presumeranno che il file esista se era in una presa try, che aggiunge alla confusione generale di un programma.

Ci sono molte situazioni in cui scriverò un metodo che recupera qualche valore da un database. Mille cose potrebbero andare storte, e vedendo come ho bisogno solo di una piccola informazione, è scomodo circondare la chiamata con una lista di cattura che contiene 5 diverse eccezioni. Quindi, rileverò eccezioni nel metodo di recupero. Se qualcosa va storto, prendo l'azione appropriata per chiudere la connessione al database o whatnot nella clausola finally e restituire null. Questa è una buona pratica non solo perché semplifica il tuo codice ma anche perché "null" invia lo stesso messaggio che potresti ottenere da un'eccezione .. che qualcosa non è andato come previsto. Gestisci le specifiche delle eccezioni nel metodo di recupero, ma gestisci cosa fare quando le cose non vanno come pianificato nel lato ricevente controllando per vedere se il risultato è stato nullo.

Ad esempio:

Integer getUserCount() {
   Integer result = null;
   try {
      // Attempt to open database and retrieve data
   } catch (TimeoutException e) {
      logger.error("Got a watch?");
   } catch (MissingDatabaseException e) {
      logger.error("What are you smoking?");
   } catch (PermissionsToReadException e) {
      logger.error("Did you *really* think you were getting away with that?");
   } catch (PressedSendButtonToHardException e) {
      logger.error("Seriously.. just back away from the computer... slowly..");
   } catch (WTFException e) {
      logger.error("You're on your own with this one.. I don't even know what happened..");
   } finally {
      // Close connections and whatnot
   }
   return result;
}

void doStuff() {
   Integer result = getUserCount();
   if(result != null) {
       // Went as planned..
   }
}

Sì, si sta gestendo correttamente le eccezioni del run time non è una buona pratica. Il motivo è che è considerato costoso / a uso intensivo di memoria.