Assertions Java sous-utilisées

Question

Je me demande pourquoi le mot clé assert est si peu utilisé en Java? Je ne les ai presque jamais vues utilisées, mais je pense qu'elles sont une bonne idée. Je préfère certainement beaucoup la brièveté de:

assert param != null : "Param cannot be null";

à la verbosité de:

if (param == null) {
    throw new IllegalArgumentException("Param cannot be null");
}

Je pense qu'ils sont sous-utilisés parce que

• Ils sont arrivés relativement tard (Java 1.4), date à laquelle de nombreuses personnes avaient déjà établi leur style de programmation Java / habitude
• Ils sont désactivés à l'exécution par défaut

Answer 1

Les

assertions servent théoriquement à tester les invariants , les hypothèses selon lesquelles doit être vraie pour que le code se termine correctement.

L'exemple présenté teste une entrée valide, ce qui n'est pas un usage courant pour une assertion, car elle est généralement fournie par l'utilisateur.

Les assertions ne sont généralement pas utilisées dans le code de production car il existe une surcharge et il est supposé que les situations dans lesquelles les invariants échouent ont été interceptées comme des erreurs de codage lors du développement et des tests.

Votre remarque sur leur arrivée " tardive " java est également une raison pour laquelle ils ne sont pas plus largement vus.

De plus, les frameworks de tests unitaires permettent en partie au besoin que les assertions programmatiques soient externes au code en cours de test.

Answer 2

C'est un abus d'assertions que de les utiliser pour tester les entrées de l'utilisateur. Lancer une IllegalArgumentException sur une entrée non valide est plus correct, car cela permet à la méthode appelante d'attraper l'exception, d'afficher l'erreur et de faire ce qu'il faut (demander à nouveau l'entrée, quitter, peu importe).

Si cette méthode est une méthode privée dans l'une de vos classes, l'assertion est correcte, car vous essayez simplement de vous assurer que vous ne lui passez pas accidentellement un argument nul. Vous testez avec des assertions activées et, une fois que vous avez testé tous les chemins d'accès et que vous n'avez pas déclenché l'assertion, vous pouvez les désactiver pour ne pas gaspiller de ressources. Ils sont également utiles comme commentaires. Un assert au début d'une méthode est une bonne documentation pour que les responsables maintiennent qu'ils doivent suivre certaines conditions préalables, et un assert à la fin avec un postcondition indique ce que la méthode devrait être. Faire. Ils peuvent être aussi utiles que des commentaires. plus, car avec des affirmations sur, ils testent réellement ce qu'ils documentent.

Les assertions sont destinées à tester / déboguer et non à vérifier les erreurs. C’est pourquoi elles sont désactivées par défaut: pour décourager les utilisateurs d’utiliser des assertions pour valider les entrées utilisateur.

Answer 3

De Programmation avec assertions

  

Par défaut, les assertions sont désactivées au moment de l'exécution. Deux commutateurs de ligne de commande vous permettent d’activer ou de désactiver sélectivement les assertions.

Cela signifie que si vous n'avez pas un contrôle total sur l'environnement d'exécution, vous ne pouvez pas garantir que le code d'assertion sera même appelé. Les assertions sont destinées à être utilisées dans un environnement de test, pas pour le code de production. Vous ne pouvez pas remplacer la gestion des exceptions par des assertions, car si l'utilisateur exécute votre application avec les assertions désactivées ( par défaut ), tout votre code de gestion des erreurs disparaît.

Answer 4

Dans "Effective Java", Joshua Bloch a suggéré (dans la rubrique "Vérification de la validité des paramètres") que (en quelque sorte comme une règle simple à adopter), pour les méthodes publiques, nous validerons les arguments et lancerons l'exception nécessaire. si elle est trouvée invalide, et pour les méthodes non publiques (qui ne sont pas exposées, vous devez en assurer la validité en tant qu'utilisateur), nous pouvons utiliser l'assertion à la place.

yc

Answer 5

@Don, vous êtes frustré que les assertions soient désactivées par défaut. J'étais aussi, et j'ai donc écrit ce petit plugin javac qui les insère (c'est-à-dire qu'il émet le bytecode pour si (! Expr) renvoie Ex plutôt que ce bytecode d'assertion idiot.

Si vous incluez fa.jar dans votre classpath lors de la compilation du code Java, il fera sa magie et dire

Note: %n assertions inlined.

http://smallwiki.unibe.ch/adriankuhn/javacompiler/forceassertions et alternativement sur github https://github.com/akuhn/javac

Answer 6

Je ne suis pas sûr de savoir pourquoi vous vous efforceriez d'écrire des assertions et de les remplacer par une instruction de condition if si standard, pourquoi ne pas simplement écrire les conditions comme si elles étaient en premier lieu?

Les assertions sont uniquement destinées aux tests et ont deux effets secondaires: des binaires plus volumineux et des performances dégradées lorsqu'ils sont activés (c'est pourquoi vous pouvez les désactiver!)

Les assertions ne doivent pas être utilisées pour valider des conditions, car cela signifie que le comportement de votre application est différent au moment de l'exécution, lorsque les assertions sont activées / désactivées, ce qui est un cauchemar!

Answer 7

Les assertions sont utiles car elles:

• récupérez les erreurs de programmation tôt "
• code du document à l'aide du code

Considérez-les comme une auto-validation du code. S'ils échouent, cela signifie que votre programme est en panne et doit cesser. Allumez-les toujours lors des tests unitaires!

Dans le programmeur pragmatique , ils recommandent même de les laisser fonctionner en production.

  

Laisser les assertions activées

     

Utilisez des assertions pour prévenir l'impossible.

Notez que les assertions émettent AssertionError si elles échouent, elles ne sont donc pas interceptées par catch Exception.

Answer 8

Les assertions sont très limitées: vous ne pouvez tester que des conditions booléennes et vous devez écrire le code d'un message d'erreur utile à chaque fois. Comparez ceci à la fonction assertEquals () de JUnit, qui permet de générer un message d'erreur utile à partir des entrées et même d'afficher les deux entrées côte à côte dans l'EDI dans un coureur JUnit.

En outre, vous ne pouvez pas rechercher d'assertions dans les IDE que j'ai vus jusqu'à présent, mais chaque IDE peut rechercher des invocations de méthodes.

Answer 9

En fait, ils sont arrivés en Java 1.4

Je pense que le principal problème est que, lorsque vous codez dans un environnement où vous ne gérez pas directement les options jvm comme dans les serveurs Eclipse ou J2EE (dans les deux cas, il est possible de modifier les options jvm mais vous devez effectuer une recherche approfondie dans trouver où cela peut être fait), il est plus facile (je veux dire, cela nécessite moins d’efforts) d’utiliser si et des exceptions (ou pire de ne rien utiliser).

Answer 10

Comme d'autres l'ont déjà indiqué, les assertions ne sont pas appropriées pour valider les entrées de l'utilisateur.

Si vous êtes préoccupé par la verbosité, je vous recommande de consulter une bibliothèque que j'ai écrite: https: // bitbucket .org / cowwoc / exigences / . Cela vous permettra d’exprimer ces vérifications en utilisant très peu de code, et générera même le message d’erreur en votre nom:

requireThat("name", value).isNotNull();

et si vous insistez pour utiliser des assertions, vous pouvez le faire aussi:

assertThat("name", value).isNotNull();

La sortie ressemblera à ceci:

java.lang.NullPointerException: name may not be null

Answer 11

tl; dr

• Oui, utilisez les tests d'assertion en production lorsque cela vous semble judicieux.
• Utilisez d'autres bibliothèques ( JUnit , AssertJ , Hamcrest , etc.) plutôt que la fonction intégrée assert si vous le souhaitez.

La plupart des autres réponses de cette page affichent la maxime "Les assertions ne sont généralement pas utilisées dans le code de production". Bien que cela soit vrai dans les applications de productivité telles que les logiciels de traitement de texte ou les tableurs, dans les applications professionnelles personnalisées où Java est si couramment utilisé, le test d'assertion en production est extrêmement utile et courant.

Comme beaucoup de maximes dans le monde de la programmation, ce qui est vrai au départ dans un contexte est mal interprété, puis mal appliqué dans d’autres.

Applications de productivité

Cette maxime de "Les assertions ne sont généralement pas utilisées dans le code de production", bien que courante, est incorrecte.

Le test d'assertion formalisé a été créé avec des applications telles qu'un traitement de texte tel que Microsoft Word ou une feuille de calcul telle que Microsoft Excel . Ces applications peuvent appeler un tableau d'assertions de tests d'assertion à chaque frappe effectuée par l'utilisateur. Une telle répétition extrême a eu de graves conséquences sur les performances. Ainsi, seules les versions bêta de ces produits à distribution limitée avaient des assertions activées. Ainsi la maxime.

Applications professionnelles

En revanche, dans les applications orientées entreprises pour la saisie de données, les bases de données ou d’autres traitements de données, l’utilisation du test d’assertion en production est extrêmement utile. La performance insignifiante sur les performances les rend assez pratiques - et communes.

Tester les règles commerciales

La vérification des règles de votre entreprise lors de l’exécution de la production est tout à fait raisonnable et devrait être encouragée. Par exemple, si une facture doit toujours contenir un ou plusieurs postes, écrivez un test d'assertion pour que le nombre de postes de la facture soit supérieur à zéro. Si un nom de produit doit comporter au moins 3 caractères, écrivez une assertion testant la longueur de la chaîne. Ces tests n'ont pas d'impact significatif sur les performances en production.

Conditions d'exécution

Si votre application s'attend à ce que certaines conditions soient toujours vraies lorsque votre application s'exécute en production, écrivez ces attentes dans votre code en tant que tests d'assertion.

Si vous vous attendez à ce que ces conditions échouent raisonnablement, n'écrivez pas les tests d'assertion. Peut-être jeter certaines exceptions. Ensuite, essayez de récupérer si possible.

contrôles de santé mentale

Les contrôles de cohérence lors de la production sont également tout à fait raisonnables et doivent être encouragés. . Tester quelques conditions arbitraires que l’on n’imaginait pas être fausses a sauvé mon bacon dans de nombreuses situations lorsqu’un événement bizarre s’est produit.

Par exemple, tester le fait d’arriver à un centime (0,05) au centime d’obtenir un centime (0,05) dans une certaine bibliothèque m’a aidé à être l’un des premiers à découvrir un défaut technologique en virgule flottante proposé par Apple dans leur logiciel. Rosetta lors de la transition de PowerPC à Intel. Un tel défaut atteignant le public aurait semblé impossible. Mais étonnamment, la faille avait échappé à l’avis du fournisseur d'origine, Transitive, et Apple, ainsi que des premiers développeurs qui testaient les bêtas d'Apple.

(Au fait, je devrais mentionner… n'utilisez jamais