3. Emballage des exceptions

Les exceptions vérifiées semblaient cool en théorie, mais se sont avérées être une énorme frustration dans la pratique.

Supposons que vous ayez une méthode super populaire dans votre projet. Il est appelé depuis des centaines d'endroits dans votre programme. Et vous décidez d' y ajouter une nouvelle exception vérifiée . Et il se peut que cette exception vérifiée soit vraiment importante et si spéciale que seule la main()méthode sait quoi faire si elle est interceptée.

Cela signifie que vous devrez ajouter l' exception vérifiéethrows à la clause de chaque méthode qui appelle votre méthode super populaire . Ainsi que dans la throwsclause de toutes les méthodes qui appellent ces méthodes. Et des méthodes qui appellent ces méthodes.

En conséquence, les throwsclauses de la moitié des méthodes du projet obtiennent une nouvelle exception vérifiée . Et bien sûr, votre projet est couvert par des tests, et maintenant les tests ne compilent pas. Et maintenant, vous devez également modifier les clauses throws dans vos tests.

Et puis tout votre code (tous les changements dans des centaines de fichiers) devra être revu par d'autres programmeurs. Et à ce stade, nous nous demandons pourquoi nous avons apporté tant de changements sanglants au projet ? Jour(s) de travail et tests cassés - tout cela pour ajouter une exception vérifiée ?

Et bien sûr, il y a encore des problèmes liés à l'héritage et au remplacement de méthode. Les problèmes qui proviennent des exceptions vérifiées sont beaucoup plus importants que les avantages. L'essentiel est que maintenant peu de gens les aiment et peu de gens les utilisent.

Cependant, il y a encore beaucoup de code (y compris le code de la bibliothèque Java standard) qui contient ces exceptions vérifiées . Que faire d'eux ? Nous ne pouvons pas les ignorer et nous ne savons pas comment les gérer.

Les programmeurs Java ont proposé d'encapsuler les exceptions vérifiées dans RuntimeException. En d'autres termes, interceptez toutes les exceptions cochées , puis créez des exceptions non cochées (par exemple, RuntimeException) et lancez-les à la place. Faire cela ressemble à ceci:

try
{
   // Code where a checked exception might occur
}
catch(Exception exp)
{
   throw new RuntimeException(exp);
}

Ce n'est pas une très jolie solution, mais il n'y a rien de criminel ici : l'exception était simplement insérée dans un fichier RuntimeException.

Si vous le souhaitez, vous pouvez facilement le récupérer à partir de là. Exemple:

Code Note
try
{
   // Code where we wrap the checked exception
   // in a RuntimeException
}
catch(RuntimeException e)
{
   Throwable cause = e.getCause();
   if (cause instanceof Exception)
   {
      Exception exp = (Exception) cause;
      // Exception handling code goes here
   }
}







Obtenez l'exception stockée à l'intérieur de l' RuntimeExceptionobjet. La causevariable peut null

déterminer son type et la convertir en un type d'exception vérifié .