Les méthodes qui lèvent RuntimeException doivent-elles l'indiquer dans la signature de méthode?
Par exemple, de nombreuses méthodes dans les frameworks/JDK peuvent jeter
Java.lang.SecurityException
mais cela n'est pas indiqué dans la signature de la méthode (car c'est une pratique normalement réservée aux exceptions vérifiées). Je veux faire valoir que la déclaration de RuntimeExceptions dans les signatures de méthode présente de nombreux avantages (semblable à la vérification de type statique par exemple). Suis-je ivre ou non?
Je ne déclarerais pas d'exception non vérifiée dans la signature, car elle est trompeuse pour l'utilisateur de cette API. Il n'est plus évident de savoir si l'exception doit être explicitement gérée.
Le déclarer dans le javadoc est une meilleure approche car il permet à quelqu'un de le gérer s'il le juge nécessaire, mais sachant qu'il peut l'ignorer s'il le souhaite. Cela rend la séparation entre cochée et non cochée claire.
De le Oracle Java :
"S'il est si bon de documenter l'API d'une méthode, y compris les exceptions qu'elle peut générer, pourquoi ne pas spécifier également des exceptions d'exécution?" Les exceptions d'exécution représentent des problèmes qui sont le résultat d'un problème de programmation, et en tant que tel, le code client API ne peut raisonnablement pas s'attendre à en récupérer ou à les gérer de quelque manière que ce soit. Ces problèmes incluent les exceptions arithmétiques, telles que la division par zéro; les exceptions de pointeur, telles que la tentative d'accès à un objet via une référence nulle; et l'indexation des exceptions, telles que la tentative d'accès à un élément de tableau via un index trop grand ou trop petit.
Les exceptions d'exécution peuvent se produire n'importe où dans un programme, et dans un programme typique, elles peuvent être très nombreuses. Le fait d'ajouter des exceptions d'exécution dans chaque déclaration de méthode réduirait la clarté d'un programme.
Jetez un œil au javadoc pour Collection # add
Il y a toute une série d'exceptions non contrôlées mentionnées:
Throws:
UnsupportedOperationException - add is not supported by this collection.
ClassCastException - class of the specified element prevents it from being added to this collection.
NullPointerException - if the specified element is null and this collection does not support null elements.
IllegalArgumentException - some aspect of this element prevents it from being added to this collection.
Si vous avez la patience, je vous recommande de bien documenter les exceptions possibles levées par vos méthodes de cette façon. D'une certaine manière, il est encore plus important de le faire pour les exceptions non contrôlées, car les exceptions vérifiées sont quelque peu auto-documentées (le compilateur force le code appelant à les reconnaître).
À mon avis, il est préférable de déclarer les exceptions d'exécution au moins dans le javadoc pour la méthode. Le déclarer dans la signature rend encore plus évident ce qui peut arriver en cas de problème. C'est ma principale raison de proposer de fournir ces informations.
Pour info: au fil du temps (maintenant en 2017), je penche maintenant beaucoup plus pour les documenter en javadoc uniquement et éviter autant que possible les exceptions vérifiées.
À mon avis, les exceptions non vérifiées ne devraient jamais être déclarées dans la signature de la méthode car cela est contraire à leur nature.
Si, cependant, une méthode est susceptible de lever des exceptions non vérifiées, notant les circonstances probables dans @throws dans Javadoc peut être utile pour les autres invoquant la méthode pour comprendre ce qui peut mal tourner. Ceci n'est utile que pour les exceptions que les appelants sont susceptibles de gérer (comme un NPE en raison d'une mauvaise entrée, etc.)
Si vous écrivez une API pour une utilisation par d'autres, il y a de bonnes raisons pour une documentation explicite de votre intention dans l'API et il n'y a aucun inconvénient à déclarer des RuntimeExceptions dans la signature de la méthode.
Cela a à voir avec la discussion concernant exceptions vérifiées . La plupart conviendraient que les exceptions ne devraient pas être déclarées dans les signatures de méthodes.
Il y a aussi un discussion concernant la façon dont les exceptions d'exécution doivent être utilisées. Je suis d'accord avec une affiche que les exceptions d'exécution devraient indiquer une erreur de programmation ou une condition fatale. Il n'y a donc pas beaucoup de mérite à les déclarer dans la signature. Chaque méthode pourrait potentiellement en passer par une.