Lorsque vous faites des chèques nuls dans le code Java et que vous lancez IllegalargumentExceptions des valeurs NULL, quel type de modèle de message utilisez-vous?
Nous avons tendance à utiliser quelque chose comme celui-ci P>
public User getUser(String username){
if (username == null){
throw new IllegalArgumentException("username is null");
}
// ...
}
4 Réponses :
est null , puisque l'argument est toujours null ..
Cependant, pourquoi ne pas simplement lancer une nullpointerException sans message?
Jeter NullpointerException sans message n'est pas bon, car il n'est pas facile de se séparer d'une nullcointException accidentelle
Jeter une exception sans message est souvent (sinon toujours) une mauvaise idée. L'exception seule est assez informative assez informative pour comprendre ce qui s'est mal passé.
@Timo Westkämper 1 sec plus rapide (:
Mieux encore: Jetez NPE avec le nom de l'argument comme message. Pas besoin de verbosité mais donnant le nom de l'argument est une information utile.
@Timo c'est une NPE. Bien sûr, c'est accidentel! Si vous pensez que l'ajout du nom de l'argument est important, vos méthodes ont clairement trop de paramètres et vous utilisez beaucoup trop de nullables.
Lancer une exception de pointeur NULL sans message signifie qu'un programmeur doit réellement regarder le code source pour identifier ce qui a provoqué l'exception basée sur le seul numéro de ligne. Vous en tant que programmeur sait Qu'est-ce qui ne va pas - pourquoi ne pas dire?
@ Tom-Hawtin-tackline, pourquoi se soucier d'écrire des chèques nulles qui jettent des NPES sans message, ils ont l'air identique à celui des NPES du système. Lorsque j'écris des chèques, je souhaite fournir plus d'informations.
@Timo - Si cela vous fait sentir mieux d'ajouter un message, allez-y. Cependant, de nombreux développeurs Java expérimentés pensent qu'il n'ajoute aucune valeur réelle. Le développeur va de toute façon regarder le code source.
Vous devez prendre en compte la fréquence à laquelle ces messages sont synchronisés avec les noms de paramètres réels par les refacteurs. J'ai également vu des cas où le nom du paramètre cité ne correspond même pas au nom de paramètre utilisé dans l'interface, le client accède à la méthode, il est donc purement déroutant. Surtout, je crois fermement qu'au moins 95% du temps que ce message ne va pas aider le programmateur de débogage un bit. Il va regarder le code; S'il y avait plusieurs arguments, il aurait pu être, il va regarder la ligne de la trace de la pile ... il ira généralement bien.
Depuis l'exception code> code> est lancée en raison d'une vérification de préconditionnement en panne, je pense que je pense que simplement indiquer un fait, vous devriez indiquer la exigence em> qui a été violée. C'est-à-dire au lieu de dire que comme un conseil, vous pouvez utiliser l'une des nombreuses bibliothèques conçues pour faciliter des contrôles de préconditionnement. Beaucoup de code à Guava utilise com.google.common.base.preconditions code> p> Des méthodes statiques simples à appeler au début de vos propres méthodes pour vérifier les arguments et l'état correct. Cela permet des constructions telles que p>
"nom d'utilisateur est null" code>, disons "nom d'utilisateur ne doit pas être null" code>. P>
sur l'utilisation de bibliothèques pour la condition préalable Vérifications h3>
// Awkward!
checkArgument(count > 0, "is negative or zero: %s", count);
checkNotNull(username, "username is null");
@polygenLubrançants, je ne sais pas si je suis d'accord sur la question de type d'exception, mais la première partie de votre réponse est vraiment bonne. Merci!
"Convention dicte" ne suffit pas, en utilisant IllegalArgumentException pour des contrôles explicites et des NPE pour quelque chose que le système ait plus de sens pour moi, mais il est bon de savoir qu'il y a d'autres opinions;)
Le débat de l'IAE vs NPE pour les arguments NULL est vieux. Il y a beaucoup de sens pour l'IAE, mais il y a aussi le poids de nombreuses années de convention derrière la NPE. Pour Préconditions.Checknotnull Nous avons dû choisir l'un ou l'autre et je suis allé avec NPE. Un avantage de la NPE est que si votre méthode change de ne pas le vérifier explicitement (juste la déséroférance) de vérifier explicitement, ou inversement, le type d'exception ne change pas. Certaines personnes croient que vous devriez toujours vérifier complètement tout, même si la même exception serait lancée deux lignes, mais je vois cela comme une perte de temps et d'espace.
(suite) Le bon endroit pour être tous "complet" et "complet" à ce sujet est dans votre tests unitaires , pas le code de mise en œuvre.
@Kevin, pourriez-vous expliquer davantage pourquoi vous avez choisi NPE? Aussi, j'aimerais savoir pourquoi ces préconditions.Check * a été introduite? Pour changer les trois lignes faisant chèque + jeter à une seule ligne?
Question 1: Il n'y a pas beaucoup plus d'expliquer. Comme je l'ai dit, il y avait le "poids de nombreuses années de convention" derrière elle, et notre objectif n'était pas d'essayer de faire de la convention, mais de rationaliser ce que nos utilisateurs faisaient déjà. Question 2: Oui, c'est à peu près tout.
Je suggérerais de dire car il est si mortel qu'un programmeur doit le regarder quand même. Référence de l'extrait de code fautif dans le message d'exception est la chose la plus actif que je puisse imaginer.
Approche intéressante. Merci d'avoir partagé! Mais réparer le cas pour le nom d'utilisateur. (Nom d'utilisateur! = Nom d'utilisateur)
J'espère un détail mineur - sauf si, bien sûr, vous avez à la fois un nom d'utilisateur et un nom d'utilisateur comme paramètres. :)
Bien oui, mais ça a l'air déroutant. Mais peut-être que c'est aussi une "meilleure pratique" que je ne suis pas au courant;)
Je serais enclin à écrire ceci:
public User getUser(String username){
if (username == null){
throw new NullPointerException("username is null");
}
if (username.length() == 0) {
throw new IllegalArgumentException("username is empty");
}
// ...
}
C'est pourquoi j'aime les références de const en C ++
@Viktor Sehr ah ha. Il y a donc une raison d'aimer les références de const en C ++ - il est à éviter "est" vs "était" arguments.
Je suis légèrement amusé que la question de ce que c'est vs était suffisamment importante pour que quiconque soit même demander. J'applaudais que vous souhaitez écrire le meilleur code que vous pouvez, mais avec tout le respect due, il est peut-être temps de réexaminer les problèmes de qualité de code.
@ Kevin-Bourrillion, bien sûr, je me rends compte qu'il y a des questions plus importantes, je voulais juste entendre des opinions sur la question. "Peut-être qu'il est temps de réexaminer quels problèmes de qualité de code importent vraiment.", ce serait ma prochaine question;)