Je suis tenté d'ajouter un suffixe comme "EX" pour différencier des méthodes (avec des signatures similaires) qui jettent des exceptions de celles qui ne le font pas.
Y a-t-il une telle convention?
11 Réponses :
Oui, vous les nommez les mêmes que les méthodes qui ne le font pas.
n'est-ce pas suffisamment spécifique d'exception?
Edit: Si vous avez des méthodes similaires qui jettent / ne pas lancer, je recommande le parse tryparse modèle ( parse étant remplacé par le opération). .NET Framework l'utilise fréquemment ( Dictionnaire moniteur.justeur , int.tryparse , etc., etc.) .
Pourquoi feriez-vous une telle chose en Java? Il a déjà des spécificateurs d'exception intégrés dans la langue. Le compilateur vous empêchera d'appeler une méthode qui jette explicitement une exception sans que certaines mesures soient prises de votre part pour gérer ou permettre à l'exception de se propager?
Ne faites pas ça.
Ceci est comme demander "Y a-t-il une convention de dénomination pour des méthodes qui prennent deux cordes comme paramètres".
Java a vérifié des exceptions, ce qui signifie que vous devez déclarez-les quand même. Donc, vous pouvez facilement voir si une exception sera lancée et quel type d'exception. Vous ne pouvez même pas compiler le code qui appelle la méthode sans ajouter de code de manutention d'exception.
Mise à jour: Il semble que votre intention est d'avoir des méthodes qui vérifient si une certaine condition est vraie, mais vous Vous ne voulez pas revenir simplement faux, mais jetez une exception si la condition n'est pas remplie, de sorte que vous puissiez également transmettre un message d'explication (à l'exception). Je pense qu'un préfixe "affirmer" ou "s'assurer" a du sens:
Les exceptions font partie de la signature de méthode en Java, une telle convention de dénomination serait donc redondante.
Notation hongroise pour des méthodes qui lancent des exceptions? Quel Horreur!
Vous voulez dire des exceptions cochées ou non cochées? Pourquoi voudriez-vous faire cela sur Terre?
Lorsque vous y réfléchissez, vous devez ajouter votre convention à chaque méthode, car il y a toujours le potentiel d'erreur ou de NPE ou une autre chose qui pourrait aller mal.
La clause "lancers" suffit lorsque vous avez vérifié des exceptions, et il n'y a pas de bon objectif sur la Terre verte de Dieu pour des exceptions non vérifiées.
Ne le faites pas. S'il vous plaît.
Il n'y a pas de convention et l'ajout d'un ex rendra le nom plus difficile à lire et à la recherche du programmeur Java moyen.
Mais parfois, je pouvais imaginer que votre code rendrait votre code plus rapide compréhensible d'ajouter un essai à des méthodes susceptibles de lancer une exception. Surtout si elles sont décochées.
Il n'est pas nécessaire de trouver quelque chose de moche comme on pouvait être trouvé dans de nombreux programmes C / C ++ où vous utilisez _Name ou MNName pour les membres ou l'ivivelle pour les entiers. Mais en Java, il y a aussi des conventions aussi. Si une méthode retournera un entier, il est préfixé avec IS ... SET, GET et TEST sont les exemples les plus utilisés pour cela. Toutes ces choses sont documentées dans l'en-tête de méthode, via des annotations de type retour, etc. mais ajoutant un mot au nom de la fonction facilite et plus rapide de lire et de comprendre.
Pourquoi ne pas utiliser d'essayer de donner aux programmeurs de lire votre code un indice subconscient que cette méthode est susceptible de lancer une exception. Comme trycopyfile au lieu de trywritefile.
Je pense que le préfixe "essayer" n'est pas si bon. Pour moi, cela semble allusion à ne pas jeter une exception. Comme Lock.tryLock (), qui va essayer d'obtenir une serrure, mais retourne false si cela n'était pas possible.
Il n'y en a pas au courant.
À mon avis, le seul moment où quelque chose comme ça a du sens est dans des cas de test unitaires (par exemple, TestFooExpectringException ())). Mais ce n'est pas vraiment ce dont vous parlez.
Il n'y a pas de convention de ce type car chaque méthode peut lancer des exceptions, que vous les déclarais ou non. Il est également quelque peu redondant en ce jour et Âge des info-bulles IDE (sauf si vous n'utilisez pas d'IDE bien sûr).
Je suis curieux de savoir pourquoi vous êtes tenté d'utiliser une telle convention de dénomination cependant.
De temps en temps, vous courez dans un cas où il pourrait être logique d'avoir un nom de méthode comme mais le point ici n'est pas "Méthode 2 jette une exception, la méthode 1 ne" pas "- car, comme mentionné ci-dessus, tout code pourrait lancer un Même alors, le code serait généralement plus propre si vous pouviez simplement vous échapper avec un comportement ou l'autre, et appelez la méthode Un parallèle utile ici pourrait être Distinction entre Systems Hongrois et Apps Hongrois en notation hongroise. (Voir aussi Cette pièce sur les conventions de codage de Joel sur le logiciel.)
appeler votre méthode getafely () (retourne une valeur par défaut dans le cas où la valeur réelle est invalide , pour le code qui ne se soucie pas trop de valeurs réelles VS PlacesLoises) ou de son converse getorblowup () (pour le code Fail-Fast où une valeur manquante est techniquement possible mais indique un bogue dans le code qui est censé définir la valeur).
runtimeexception . Le point est que les deux méthodes ont une sémantique de traitement des erreurs différente, spécifique à des cas d'utilisation différents, et c'est ce que les noms de méthode tentent de capturer.
obtenez () . .
comptage devient icount . C'est la forme la plus courante de la notation hongroise et de l'IMHO c'est (1) assez inutile avec une IDE moderne et (2) potentiellement trompeuse, si une personne change la déclaration de type sans renommer la variable.
index représentant une ligne de données devient drindex et index représentant une colonne d'annotation devient acindex . Ceci est beaucoup plus utile et beaucoup moins susceptible de causer des problèmes.
getex () est Systems Hongrois.
Si vous avez besoin de ces méthodes différenciées, je suis sûr que vous pouvez le faire dans le nommer sans utiliser de suffixe ou quoi que ce soit, ce qui est (comme d'autres l'ont souligné) plutôt horrible. Pourquoi avoir: et (dire) lorsque vous pourriez en faire une partie significative du nom par Transférer l'intention réelle: ... ou un nombre quelconque d'autres noms (probablement meilleurs) qui transmettent réellement l'intention plutôt que de compter sur un suffixe déroutant.
ne l'ajoutez généralement pas aux noms de méthodes.
Ajouter des lancers à la place. mais personnellement, j'aime pour getter par exemple https: / /developers.google.com/protocol-buffers/docs/reeference/java/com/google/protobuf/truct
Spring LDAP a 4 méthodes "authentifier" qui ne jettent pas d'exceptions. J'aimerais ajouter une nouvelle méthode "authentification" qui * fait ^ excepte des exceptions et il serait préférable de nommer ces nouvelles méthodes quelque chose qui les différencierait de ceux qui ne le font pas.
Il existe une convention de dénomination pour les méthodes d'opposition, les meilleurs efforts qui ignorent les exceptions et la continuité: les méthodes appelées SafeClose ne jettent pas NullPointerExceptions, ni IOException, ou SQLException, même lorsque l'opération de fermeture a échoué.
J'ai besoin d'attraper l'authentificationException à partir des méthodes "authentifier" afin que je puisse remettre la raison de l'échec de l'utilisateur.
Je suis fier d'annoncer que les développeurs Spring LDAP ont mis en œuvre ma demande de livraison de l'authentificationException.