Les méthodes qui lèvent une RuntimeException doivent-elles l'indiquer dans leur signature ?

Question

Par exemple, de nombreuses méthodes dans les frameworks/JDK peuvent lancer la commande

java.lang.SecurityException

mais cela n'est pas indiqué dans la signature de la méthode (puisque c'est une pratique normalement réservée aux exceptions vérifiées). Je veux faire valoir que la déclaration des RuntimeExceptions dans les signatures de méthodes présente de nombreux avantages (comme la vérification statique des types, par exemple). Suis-je ivre ou autre ?

Answer 1

Je ne déclarerais pas une exception non vérifiée dans la signature, car cela induit en erreur l'utilisateur de cette API. Il n'est plus évident de savoir si l'exception doit être traitée explicitement.

Le déclarer dans la javadoc est une meilleure approche car cela permet à quelqu'un de le gérer s'il pense que c'est nécessaire, tout en sachant qu'il peut l'ignorer s'il le souhaite. Cela rend la séparation entre vérifié et non vérifié claire.

Answer 2

De le tutoriel Oracle Java :

"Si c'est si bien de documenter l'API d'une méthode, y compris les exceptions qu'elle peut lancer, pourquoi ne pas spécifier aussi les exceptions d'exécution ?" Runtime d'exécution représentent des problèmes qui sont le résultat d'un problème de programmation. programmation, et en tant que tels, le code client de l'API ne peut pas raisonnablement ne peut pas raisonnablement s'attendre à ce que le code client de l'API s'en remette ou les traite de quelque manière que ce soit. Ces problèmes incluent les exceptions arithmétiques, telles que la division par zéro ; exceptions de pointeur, telles que la tentative d'accès à un objet par le biais d'une référence référence nulle ; et les exceptions d'indexation, telles que la tentative d'accès à un élément de tableau par le biais d'un index trop élevé. élément d'un tableau par le biais d'un index trop grand ou trop petit.

Les exceptions d'exécution peuvent survenir n'importe où dans un programme, et dans un programme typique, elles peuvent être très nombreuses. typique, elles peuvent être très nombreuses. Devoir ajouter des exceptions d'exécution dans chaque déclaration de méthode réduirait la clarté d'un programme.

Answer 3

Jetez un œil à la javadoc de Collection#add

Il y a toute une série d'exceptions non vérifié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 documenter minutieusement les exceptions possibles lancé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 vérifiées, car les exceptions vérifiées sont en quelque sorte auto-documentées (le compilateur oblige le code appelant à les reconnaître).

Answer 4

De mon point de vue, il est préférable de déclarer les exceptions d'exécution au moins dans la javadoc de la méthode. Le fait de les déclarer dans la signature rend encore plus évident ce qui peut se passer lorsque quelque chose ne va pas. C'est la raison principale pour laquelle je suggère de fournir cette information.

Answer 5

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

Toutefois, si une méthode est susceptible de lever des exceptions non vérifiées, le fait de noter les circonstances probables dans @throws dans la Javadoc peut aider les autres personnes invoquant la méthode à comprendre ce qui peut se passer. Cela n'est cependant utile que pour les exceptions que les appelants sont susceptibles de pouvoir gérer (comme un NPE dû à une mauvaise entrée, etc.).