La capture d'une exception de pointeur nul est-elle une odeur de code ?

Question

Récemment, un de mes collègues a écrit du code pour attraper une exception de pointeur nul autour d'une méthode entière, et retourner un seul résultat. J'ai fait remarquer que le pointeur nul pouvait avoir plusieurs causes, et nous avons donc modifié le code pour le remplacer par une vérification défensive d'un seul résultat.

Cependant, le fait d'attraper une exception NullPointerException me semblait erroné. Dans mon esprit, les exceptions de pointeurs nuls sont le résultat d'un mauvais code et ne sont pas une exception attendue dans le système.

Existe-t-il des cas où il est judicieux d'attraper une exception de pointeur nul ?

Answer 1

Oui, attraper n'importe quel RuntimeException est presque toujours une odeur de code. Le site C2 Wiki semble être d'accord.

Une exception serait probablement certains morceaux de code spécialement défensifs qui exécutent du code aléatoire provenant d'autres modules. Des exemples de telles structures défensives seraient les modules EDT , ThreadPools/Exécuteurs et système de plugins.

Answer 2

Je ne vois qu'une seule utilité à attraper un NullPointerException :

catch (NullPointerException) {
    ApplyPainfulElectricShockToProgrammer();
}

Answer 3

J'ai dû attraper des exceptions de type nullpointer à cause d'un bogue dans une bibliothèque tierce. La bibliothèque que nous utilisions générait cette exception, et nous ne pouvions rien y faire.

Dans ce cas, c'est OK pour l'attraper, sinon non.

Answer 4

Ça dépend.

Quelle est l'expérience de ce collaborateur ? Fait-il cela par ignorance/paresse ou y a-t-il une vraie bonne raison à cela ? ( comme si c'était le fil conducteur au-dessus de tout le reste et qu'il ne devait jamais mourir ? )

Dans 90% des cas, attraper une exception d'exécution est une erreur, dans 99% des cas, attraper une exception NullPointerException est une erreur ( si la raison est "J'en recevais beaucoup..." alors tout le programmeur a tort et vous devriez faire attention au reste du code qu'il fait ;)

Mais dans certaines circonstances, il peut être acceptable d'attraper une NullPointerException.

Answer 5

En général, je pense que c'est une odeur de code ; il me semble que les vérifications défensives sont meilleures. J'étendrais cela pour couvrir la plupart des exceptions non vérifiées, sauf dans les boucles d'événements, etc. qui veulent attraper toutes les erreurs pour les rapporter ou les consigner.

L'exception à laquelle je peux penser concerne un appel à une bibliothèque qui ne peut pas être modifiée et qui peut générer une exception de pointeur nul en réponse à un échec d'assertion difficile à vérifier de manière proactive.