1. Aperçu
Il existe la clé assert dans les langages C et C++, qui signifie assertion.
En Java, il existe également le mot-clé assert, qui signifie assertion. L'usage et la signification sont similaires.
2. Grammaire
En Java, le mot-clé assert a été introduit à partir de JAVA SE 1.4. Afin d'éviter les erreurs causées par l'utilisation du mot-clé assert dans les anciennes versions du code Java, Java n'active pas la vérification des assertions par défaut lors de l'exécution (à l'heure actuelle, toutes les instructions Assertion le seront. être ignoré !), si vous souhaitez activer la vérification des assertions, vous devez l'activer avec le commutateur -enableassertions ou -ea.
La syntaxe du mot clé assert est très simple et a deux utilisations :
1. affirmer <expression booléenne>
Si <expression booléenne> est vraie, l'exécution du programme continue.
Si faux, le programme renvoie une AssertionError et termine l'exécution.
2. assert <expression booléenne> : <expression du message d'erreur>
Si <expression booléenne> est vraie, l'exécution du programme continue.
Si c'est faux, le programme renvoie java.lang.AssertionError et saisit <expression de message d'erreur>.
3. Exemples d'applications
Un exemple est donné ci-dessous pour illustrer son utilisation :
Copiez le code comme suit :
classe publique AssertFoo {
public static void main(String args[]) {
//Le résultat de l'assertion 1 est vrai, puis continuez l'exécution.
affirmer vrai;
System.out.println("Il n'y a aucun problème avec l'assertion 1, Go!");
System.out.println("/n-----------------/n");
//Le résultat de l'assertion 2 est faux et le programme se termine
assert false : "L'assertion a échoué, les informations de cette expression seront affichées lorsqu'une exception est levée !";
System.out.println("Il n'y a aucun problème avec l'assertion 2, Go!");
}
}
Enregistrez le code dans C:/AssertFoo.java, puis exécutez-le comme suit et affichez la sortie de la console :
1. Compiler le programme :
C:/>javac AssertFoo.java
2. Le programme est exécuté par défaut sans activer le commutateur -ea :
C:/>java AssertFoo
L'affirmation 1 est très bien, allez-y !
-------------------
L'assertion 2 ne pose aucun problème, allez-y !
3. Activez le commutateur -ea et exécutez le programme :
C:/>java -ea AssertFoo
L'affirmation 1 est très bien, allez-y !
-------------------
Exception dans le thread "main" java.lang.AssertionError : l'assertion a échoué, les informations de cette expression seront
Sera affiché lorsqu'une exception est levée !
sur AssertFoo.main (AssertFoo.java:10)
4. Piège
Le mot-clé assert est simple à utiliser, mais utiliser assert vous fera souvent tomber dans un piège de plus en plus profond. Devrait être évité. Après recherche, l’auteur a résumé les raisons suivantes :
1. Le mot-clé assert doit être explicitement activé au moment de l'exécution pour prendre effet, sinon votre assertion n'aura aucun sens. Actuellement, les outils IDE Java traditionnels n'activent pas la fonction de vérification des assertions -ea par défaut. Cela signifie que si vous utilisez les outils IDE pour coder, vous rencontrerez des problèmes lors du débogage et de l'exécution. De plus, pour les applications Web Java, le code du programme est déployé dans le conteneur et vous ne pouvez pas contrôler directement l'exécution du programme. Si vous devez activer le commutateur -ea, vous devez modifier les paramètres de configuration en cours d'exécution du conteneur Web. Cela entraîne de grands inconvénients pour la transplantation et le déploiement des programmes.
2. Utiliser assert au lieu de if est le deuxième piège. Le jugement de assert est similaire à celui de l'instruction if, mais les fonctions des deux sont essentiellement différentes : le mot-clé assert est destiné à être utilisé lors du test et du débogage du programme, mais si vous utilisez accidentellement assert pour contrôler le processus métier du programme, il ne sera pas utilisé pendant les tests et le débogage. Supprimer le mot-clé assert une fois terminé signifie modifier la logique normale du programme.
3. Si l'assertion assert échoue, le programme se terminera. Cela ne serait jamais toléré dans un environnement de production. Les erreurs potentielles dans le programme sont généralement résolues grâce à la gestion des exceptions. Mais utiliser des assertions est très dangereux. En cas d’échec, le système se bloque.
5. Réflexions sur l'affirmation
Étant donné que assert est destiné au débogage des programmes de test et non à une utilisation dans des environnements de production formels, vous devriez envisager de mieux tester JUint pour remplacer sa fonction. JUint fournit encore plus de fonctions clés que assert. Bien entendu, le débogage et les tests peuvent être effectués via le débogage IDE. De ce point de vue, l’avenir de l’assertion est sombre.
Par conséquent, vous devriez éviter d'utiliser le mot-clé assert en Java, à moins qu'un jour Java ne prenne en charge le commutateur -ea par défaut, vous pourrez alors l'envisager. Comparez les avantages et les problèmes que l'affirmation peut vous apporter. C'est le principe pour nous de choisir de l'utiliser ou non.
=================================================== ==========
commentaire:
D'un autre côté, dans certains composants open source, tels que Validator et Junit, le processus de jugement semble utiliser un style d'assertion. Il est très probable qu'un grand nombre d'assertions soient utilisées, mais l'auteur ne peut pas en être sûr avant de les examiner. code source.
S'il s'agit d'un simple test pendant la phase de développement, junit est un outil pratique et puissant. Il n'y a aucune raison de ne pas l'utiliser lors de la rédaction de vos propres assertions.
=================================================== ==========
commentaire:
Tout d’abord, il peut être utilisé dans le code de test unitaire. Junit est très intrusif. Si une grande quantité de code dans l'ensemble du projet utilise Junit, il sera difficile de le supprimer ou de choisir un autre framework. S'il existe de nombreux codes de tests unitaires et que vous souhaitez réutiliser ces cas de tests unitaires, vous devez choisir assert au lieu de junit pour faciliter l'utilisation d'autres frameworks de tests unitaires, tels que TestNG. Pour la même raison, Junit ne devrait pas du tout apparaître dans le code fonctionnel formel et assert devrait être utilisé.
assert convient principalement aux classes de base, aux classes de framework, aux classes d'interface, aux classes de code de base et aux classes d'outils. En d’autres termes, il est nécessaire de l’utiliser lorsque l’appelant de votre code est du code métier écrit par un autre programmeur, ou un autre sous-système. Par exemple, si vous créez un algorithme de tri rapide
Copiez le code comme suit :
public static List<int> quickSort(List<int> liste){
liste d'affirmations != null;
//Demander un espace temporaire
// Commencer le tri
pour(int i : liste){
//
}
}
Dans ce cas, si l'exactitude des paramètres entrants n'est pas vérifiée, une erreur de pointeur nul inexplicable sera générée. Vos appelants ne connaissent peut-être pas les détails de votre code, et déboguer une erreur de pointeur nul en profondeur dans un système est une perte de temps. Vous devez informer directement et clairement votre appelant qu'il y a un problème avec les paramètres transmis. Sinon, il soupçonnera que votre code contient un BUG. L'utilisation d'assert peut empêcher deux programmeurs de se blâmer mutuellement pour les problèmes liés au code qu'ils ont écrit.
assert s'applique aux erreurs dont vous savez exactement quelle est l'erreur, et vous et votre appelant avez convenu que votre appelant doit éliminer ou vérifier les erreurs. Vous le dites à votre appelant via une assertion. assert ne s'applique pas aux erreurs causées par des systèmes externes, telles que les erreurs dans les données saisies par l'utilisateur ou les erreurs de format dans un fichier externe. Ces erreurs ne sont pas causées par votre appelant mais par l'utilisateur, et ne constituent même pas des exceptions, car les erreurs de saisie et les erreurs de format de fichier sont courantes et ces erreurs doivent être vérifiées par le code métier.
assert est plus adapté aux classes de base, au code de framework, aux classes d'outils, au code de base et au code d'interface fréquemment appelés. C'est pourquoi il est supprimé au moment de l'exécution. Le code de test doit activer le paramètre -ea pendant la phase de test pour faciliter un test minutieux du code principal en profondeur dans le système.
La raison pour laquelle Java utilise assert moins souvent est que Java dispose d'un système OO très complet et que la conversion de type forcée se produit moins fréquemment, il n'est donc pas nécessaire de vérifier fréquemment si le type du pointeur est correct et si le pointeur est vide comme C. Dans le même temps, Java gère rarement la mémoire ou les tampons directement, il n'est donc pas nécessaire de vérifier fréquemment si le tampon entrant est vide ou a franchi la limite.
Mais bien utiliser assert peut aider à améliorer l'exactitude du code-cadre et à réduire le temps de débogage des utilisateurs du code-cadre.
=================================================== =============
commentaire:
Le but de assert est de permettre aux programmeurs de découvrir facilement leurs propres erreurs logiques sans affecter l'efficacité du programme. Les erreurs trouvées par assert ne devraient pas se produire du tout et ne peuvent pas être remplacées par des exceptions. Les exceptions sont autorisées par le système ou sont des "erreurs" incontrôlables par le système. Ce ne sont pas des problèmes logiques du programmeur.
assert doit être activé pendant le développement et désactivé après la sortie.