J'ai beaucoup utilisé ces extraits, recherchant des null
valeurs et des chaînes vides.
J'utilise les modèles "test d'argument" comme premier code dans mes méthodes pour vérifier les arguments reçus.
testNullArgument
if (${varName} == null) {
throw new NullPointerException(
"Illegal argument. The argument cannot be null: ${varName}");
}
Vous souhaiterez peut-être modifier le message d'exception pour l'adapter aux normes de votre entreprise ou de votre projet. Cependant, je recommande d'avoir un message qui inclut le nom de l'argument incriminé. Sinon, l'appelant de votre méthode devra chercher dans le code pour comprendre ce qui s'est mal passé. (Un NullPointerException
sans message produit une exception avec le message assez insensé "null").
testNullOrEmptyStringArgument
if (${varName} == null) {
throw new NullPointerException(
"Illegal argument. The argument cannot be null: ${varName}");
}
${varName} = ${varName}.trim();
if (${varName}.isEmpty()) {
throw new IllegalArgumentException(
"Illegal argument. The argument cannot be an empty string: ${varName}");
}
Vous pouvez également réutiliser le modèle de vérification null ci-dessus et implémenter cet extrait de code pour vérifier uniquement les chaînes vides. Vous utiliseriez ensuite ces deux modèles pour produire le code ci-dessus.
Le modèle ci-dessus, cependant, a le problème que si l'argument in est final, vous devrez modifier le code produit (le ${varName} = ${varName}.trim()
échouera).
Si vous utilisez beaucoup d'arguments finaux et que vous souhaitez vérifier les chaînes vides mais que vous n'avez pas à les supprimer dans le cadre de votre code, vous pouvez utiliser ceci à la place:
if (${varName} == null) {
throw new NullPointerException(
"Illegal argument. The argument cannot be null: ${varName}");
}
if (${varName}.trim().isEmpty()) {
throw new IllegalArgumentException(
"Illegal argument. The argument cannot be an empty string: ${varName}");
}
testNullFieldState
J'ai également créé des extraits de code pour vérifier les variables qui ne sont pas envoyées comme arguments (la grande différence est le type d'exception, qui est maintenant un à la IllegalStateException
place).
if (${varName} == null) {
throw new IllegalStateException(
"Illegal state. The variable or class field cannot be null: ${varName}");
}
testNullOrEmptyStringFieldState
if (${varName} == null) {
throw new IllegalStateException(
"Illegal state. The variable or class field cannot be null: ${varName}");
}
${varName} = ${varName}.trim();
if (${varName}.isEmpty()) {
throw new IllegalStateException(
"Illegal state. The variable or class field " +
"cannot be an empty string: ${varName}");
}
testArgument
Il s'agit d'un modèle général pour tester une variable. Il m'a fallu quelques années pour vraiment apprendre à apprécier celui-ci, maintenant je l'utilise beaucoup (en combinaison avec les modèles ci-dessus bien sûr!)
if (!(${varName} ${testExpression})) {
throw new IllegalArgumentException(
"Illegal argument. The argument ${varName} (" + ${varName} + ") " +
"did not pass the test: ${varName} ${testExpression}");
}
Vous entrez un nom de variable ou une condition qui renvoie une valeur, suivie d'un opérande ("==", "<", ">" etc.) et d'une autre valeur ou variable et si le test échoue, le code résultant lèvera une exception IllegalArgumentException.
La raison de la clause if légèrement compliquée, avec l'expression entière entourée d'un "! ()" Est de permettre de réutiliser la condition de test dans le message d'exception.
Peut-être que cela déroutera un collègue, mais seulement s'il doit consulter le code, ce qu'il pourrait ne pas avoir à faire si vous jetez ce genre d'exceptions ...
Voici un exemple avec des tableaux:
public void copy(String[] from, String[] to) {
if (!(from.length == to.length)) {
throw new IllegalArgumentException(
"Illegal argument. The argument from.length (" +
from.length + ") " +
"did not pass the test: from.length == to.length");
}
}
Vous obtenez ce résultat en appelant le modèle, en tapant "from.length" [TAB] "== to.length".
Le résultat est beaucoup plus drôle qu'une "ArrayIndexOutOfBoundsException" ou similaire et peut réellement donner à vos utilisateurs une chance de comprendre le problème.
Prendre plaisir!