N'est-ce pas une bonne pratique de gérer les exceptions d'exécution dans le code?

Je travaille sur une application Java et je constate que les exceptions d'exécution sont gérées à de nombreux endroits. Par exemple,

try {
    // do something
} catch(NullPointerException e) {
    return null;
}

Ma question est: quand est-ce une bonne pratique de gérer les exceptions Runtime? Quand faut-il laisser les exceptions non gérées?

Ça dépend.

Par exemple, Integer#parseIntjette NumberFormatException(qui est un RTE) si la chaîne fournie ne peut pas être analysée. Mais vous ne voulez sûrement pas que votre application plante, simplement parce que l'utilisateur a écrit "x" dans un champ de texte qui était pour des entiers? Et comment savez-vous si la chaîne peut être analysée, à moins que vous n'essayiez de l'analyser en premier? Donc dans ce cas, le RTE est juste un signal d'erreur qui devrait provoquer une sorte de message d'erreur. On pourrait dire que ce devrait être une exception vérifiée, mais que pouvez-vous faire - ce n'est pas le cas.

NullPointerExceptions sont généralement le signe d'une vérification nulle manquante. Donc, au lieu de l'attraper comme ça, vous devez ajouter la vérification nulle appropriée pour être sûr de ne pas lever l'exception.

Mais parfois, il est approprié de gérer les RunTimeExceptions. Par exemple, lorsque vous ne pouvez pas modifier le code pour ajouter la vérification null à l'endroit approprié, ou lorsque l'exception est autre chose qu'une NullPointerException.

Votre exemple de gestion des exceptions est terrible. Ce faisant, vous perdez la trace de la pile et des informations précises sur le problème. Et vous ne le résolvez pas, car vous déclencherez probablement une autre exception NullPointerException à un endroit différent et obtiendrez des informations trompeuses sur ce qui s'est passé et comment le résoudre.

Je gère les exceptions attendues là où je les attends. (Comme les erreurs de lecture / écriture DB). Exceptions inattendues Je bouillonne. Quelque part ailleurs peut-être attendre l'exception et avoir la logique pour cela.

Les exceptions devraient être juste que .. des exceptions. La meilleure pratique lors de l'utilisation d'exceptions est de les utiliser pour couvrir la situation dans laquelle quelque chose de contraire à ce que vous attendez se produit. L'exemple classique est l'exception FileNotFoundException qui est levée lorsqu'un fichier n'est tout simplement pas là. Si vous testez l'existence du fichier, vous utilisez File.exists () car vous vous contentez de pousser avec un bâton de 10 pieds pour voir si vous frappez quelque chose.

Techniquement, vous pourriez obtenir les mêmes résultats en l'entourant d'une tentative de capture et en utilisant le fichier comme s'il existait, mais A) les exceptions sont généralement coûteuses en termes de ressources et B) les programmeurs vont supposer que vous vouliez dire que le fichier existe s'il était dans une prise d'essai, ce qui ajoute à la confusion globale d'un programme.

Il existe de nombreuses situations dans lesquelles j'écrirai une méthode qui récupère une valeur dans une base de données. Un millier de choses pourraient mal tourner, et vu que je n'ai besoin que d'une petite information, il n'est pas commode d'entourer l'appel d'une liste de captures d'essai qui contient 5 exceptions différentes. Donc, je vais attraper des exceptions dans la méthode fetch. Si quelque chose ne va pas, je prends toutes les mesures appropriées pour fermer la connexion à la base de données ou tout le reste dans la clause finally et retourner null. C'est une bonne pratique non seulement parce qu'elle simplifie votre code mais aussi parce que "null" envoie le même message que vous auriez pu recevoir d'une exception .. que quelque chose ne s'est pas passé comme prévu. Gérez les spécificités des exceptions dans la méthode de récupération, mais gérez quoi faire lorsque les choses ne se passent pas

Par exemple:

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..
   }
}

oui, la gestion des exceptions d'exécution n'est pas une bonne pratique, car elle est considérée comme coûteuse / gourmande en mémoire.