Affirmer ou non une bonne pratique?
Est-il une bonne pratique d'utiliser Valoir pour les paramètres de la fonction à appliquer à leur validité. J'ai été en passant par le code source du Framework Spring et j'ai remarqué qu'ils utilisent Assert.notNull
beaucoup. Voici un exemple
public static ParsedSql parseSqlStatement(String sql) {
Assert.notNull(sql, "SQL must not be null");}
En voici une Autre:
public NamedParameterJdbcTemplate(DataSource dataSource) {
Assert.notNull(dataSource,
"The [dataSource] argument cannot be null.");
this .classicJdbcTemplate = new JdbcTemplate(dataSource);
}
public NamedParameterJdbcTemplate(JdbcOperations classicJdbcTemplate) {
Assert.notNull(classicJdbcTemplate,
"JdbcTemplate must not be null");
this .classicJdbcTemplate = classicJdbcTemplate;
}
Pour info, Le Assert.notNull
(pas le assert
déclaration) est définie dans un util classe comme suit:
public abstract class Assert {
public static void notNull(Object object, String message) {
if (object == null) {
throw new IllegalArgumentException (message);
}
}
}
- Remarque, ce n'est pas
assert
. Vous devriez toujours jeter une exception dans ce cas. Par défaut,assert
est éteint. - Je ne suis pas sûr de ce que cela
Assert
classe est utilisée pour. Je suis habitué à laassert
déclaration: java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html - Demandez-vous si le fait d'avoir des assertions est bon (oui, c'est)? Ou si l'assertion de mots clés, ce qui permet d'écrire une affirmation, puis l'éteindre pour le déploiement, est plus utile pour cet effet, puis un "régulier" si l'instruction qui lève une exception (pas sûr)?
- Désolé pour la confusion, j'ai été plus d'allusion à des Assertions, en général, pas nécessairement le mot-clé
Vous devez vous connecter pour publier un commentaire.
En principe, les assertions ne sont pas différent de beaucoup d'autres moment de l'exécution de vérifications.
Par exemple, Java lié-vérifie tous les champs d'accès au moment de l'exécution. Cela rend les choses un peu plus lent? Oui. Est-il avantageux? Absolument! Dès que out-of-lié à la violation se produit, une exception est levée et le programmeur est averti de tout bug possible! Le comportement dans d'autres systèmes où l'accès à des tableaux ne sont pas liés vérifiés sont BEAUCOUP PLUS IMPRÉVISIBLES! (souvent avec des conséquences désastreuses!).
Affirmations, si vous utilisez la bibliothèque ou de la langue de support, est semblable à l'esprit. Il y a des coûts de l'exécution, mais c'est absolument la peine. En fait, les affirmations sont encore plus précieux parce que c'est explicite, et il communique concepts de niveau plus élevé.
Utilisé correctement, le coût peut être réduit au minimum et la valeur, à la fois pour le client (qui va attraper des violations de contrat, et plutôt tôt que tard) et les développeurs (parce que le contrat est auto-application de et l'auto-documentation), est agrandie.
Une autre façon de voir les choses est de penser des affirmations comme "actif " commentaires". Il n'y a pas arguant que les commentaires sont utiles, mais ils sont PASSIFS; calcul, ils ne font rien. Par la formulation de certains concepts comme des assertions au lieu de commentaires, ils deviennent ACTIFS. En fait ils doivent détenir au moment de l'exécution; les infractions seront pris.
Voir aussi: les avantages de la programmation avec les affirmations
assert
peut être désactivé à l'aide d'une JVM option de ligne de commande. Les Assertions mises en œuvre par les OP exemple ne peut être désactivée que si la classe / méthode est conçue pour permettre.Ces assertions sont bibliothèque fournie et ne sont pas le même que le haut-
assert
mot-clé.Il y a une différence ici:
assert
s de ne pas exécuter par défaut (ils doivent être activés avec le-ea
paramètre), tandis que les affirmations fournies par leAssert
classe ne peut pas être désactivé.À mon avis (pour ce que ça vaut), c'est aussi une bonne méthode pour valider les paramètres. Si vous aviez utilisé intégrés dans les affirmations que la question titre l'indique, j'aurais fait valoir contre elle sur la base que les vérifications nécessaires ne doivent pas être amovible. Mais ce moyen est juste un raccourci pour:
... qui est toujours de bonne pratique de le faire dans les méthodes publiques.
De l'intégré dans le style de affirme est plus utile pour les situations où une condition doit toujours être vrai, ou pour des méthodes privées. Le guide de langue en introduisant des assertions a quelques bonnes lignes directrices qui sont, fondamentalement, ce que je viens de décrire.
Oui c'est une bonne pratique.
Au Printemps de cas, il est particulièrement important parce que les contrôles sont de la validation des paramètres de propriété, etc qui sont généralement à venir à partir de XML câblage des fichiers. En d'autres termes, ils sont de la validation de la webapp de configuration. Et si jamais vous ne le sérieux de Printemps à base de développement, ceux des contrôles de validation va vous épargner des heures de débogage lorsque vous faites une stupide erreur de configuration.
Mais notez qu'il y a une GRANDE différence entre une bibliothèque de classe appelé
Assert
et la Javaassert
mot-clé qui est utilisée pour définir un Java affirmation. La dernière forme d'affirmations peut être désactivé au démarrage de l'application du temps, et ne doit PAS être utilisé pour l'argument des contrôles de validation que vous voulez toujours de se produire. Clairement, le Printemps, les concepteurs pense que ce serait une très mauvaise idée pour désactiver la webapp de configuration des contrôles d'intégrité ... et je suis d'accord.Mise à JOUR
Dans Java 7 (et plus tard), l'
java.util.Objects
classe fournit unrequireNonNull
méthode pratique pour tester si un argument estnull
et lever une exception. Vous l'utilisez comme ceci:ou
Toutefois, notez que cette méthode soulève
NullPointerException
plutôt queIllegalArgumentException
.Basées sur le Soleil du guide sur des assertions, vous devriez pas utilisation des assertions pour la vérification argument dans les méthodes publiques.
En très grande et très mal conçu et maintenu des systèmes d', si vous êtes à la recherche pour améliorer la prévisibilité dans les méthodes qui sont, disons, 6000 lignes de long et personne dans la société comprend plus, il peut être utile d'utiliser l'assertion de mot-clé pour provoquer des environnements de développement pour blow up, révélant des bugs. Mais avez-vous été pour mettre en œuvre ces affirmations dans la production, vous risquez de court-circuit d'un patch que, si horriblement conçu, correction d'un problème. Vous voulez corriger ce mauvais patch en le découvrant dans l'environnement de dev, pas de production. Donc, vous tournez affirme au temps de développement, et de les désactiver dans la production.
Une autre utilisation valide de l'affirmer mot-clé au temps de développement est d'insérer des contrôles de validité des algorithmes qui doit s'exécuter dans le sous-ordre de la milliseconde fois et sont assez bien isolé de l'imprévisible ou non testé les appelants. Vous ne pouvez pas être en mesure de se permettre de conserver le contrôle de validité de la production dans un tel cas, mais il est toujours très utile dans le développement. D'autre part, si la source de l'paramètres que vous êtes la validation est imprévisible ou pourrait le devenir (s'il est déterminé en partie par la saisie de l'utilisateur, par exemple), vous pouvez probablement jamais se permettre de passer le chèque, même dans la production, et devrait prendre la performance de frapper comme un coût de faire des affaires. (Dans ce dernier cas, vous probablement ne voulez pas utiliser une assertion.) Mais vous devriez opter pour affirme à éliminer une partie de la production de la période de validité de vérifier seulement après profilage vous dit que vous ne pouvez simplement pas se permettre les frais généraux.
Oui c'est une bonne idée. Vous êtes en appliquant la passation des marchés de l'interface ou de la classe. Si il y a une violation de contrat que vous souhaitez détecter dès que possible. Le plus vous attendez le plus imprévisible, les résultats peuvent être et le plus difficile, il peut être à diagnostiquer.
Lorsque vous vérifient de manière explicite comme cela, vous devez également fournir un message d'information que lors de l'affichage dans un fichier journal peut donner un contenu utile pour les aider à trouver la cause racine ou même juste de réaliser que vous avez fait une fausse supposition au sujet de ce que le contrat est.
Je vais garder mon assertions dans la remise binaires mais avec un comportement modifié: abort n'est pas appelé, mais stacktrace est recueillie.
Plus de détails ici: http://blog.aplikacja.info/2011/10/assert-to-abort-or-not-to-abort-thats-the-question/