67 votes

Java assertions sous-utilisés

Je me demande pourquoi les "faire valoir" mot-clé est donc sous-utilisés en Java? Je l'ai presque jamais vu utilisé, mais je pense qu'ils sont une excellente idée. Certes, je préfère de beaucoup la brièveté de:

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

pour le niveau de verbosité de:

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

Mon soupçon est qu'ils sont sous-utilisés en raison

  • Ils sont arrivés relativement tard (Java 1.4), par lequel beaucoup de gens ont déjà défini leur style de programmation Java/habitude
  • Elles sont désactivées à l'exécution, par défaut, pourquoi, OH POURQUOI??

Cheers, N'

64voto

Ken Gentle Points 10162

les assertions sont, en théorie, pour les essais des invariants, des hypothèses qui doivent être vraies pour que le code se termine correctement.

L'exemple montré est des tests pour l'entrée valide, ce qui n'est pas une utilisation typique pour une affirmation, car il est généralement fourni par l'utilisateur.

Les Assertions ne sont généralement pas utilisés dans la production de code, car il existe une surcharge et il est supposé que les situations où les invariants de l'échec ont été pris comme des erreurs de codage au cours du développement et de test.

Votre remarque au sujet de leur venue "en retard" de java est aussi une raison pour laquelle ils ne sont pas plus largement vu.

Aussi, les tests unitaires cadres permettent pour certains de la nécessité pour la programmation des assertions à l'extérieur du code testé.

57voto

Adam Jaskiewicz Points 7485

C'est un abus d'affirmations à utiliser pour tester la saisie de l'utilisateur. Jetant un IllegalArgumentException sur l'entrée non valide est plus correcte, car elle permet à l'appelant de la méthode pour attraper l'exception, l'affichage de l'erreur, et faire ce qu'il doit (demander pour l'entrée de nouveau, quitter, peu importe).

Si cette méthode est une méthode privée à l'intérieur de l'une de vos classes, de l'affirmation est très bien, parce que vous êtes juste essayer de s'assurer de ne pas accidentellement en passant un argument null. Le test avec des assertions sur, et quand vous avez testé tous les chemins de travers et pas déclenché l'affirmation, vous pouvez les désactiver afin de ne pas gaspiller les ressources. Ils sont également utiles comme des commentaires. Un assert au début d'une méthode est une bonne documentation pour les responsables qu'ils devraient être à la suite de certaines conditions préalables, et un assert à la fin avec une postcondition documents de ce que la méthode doit être en train de faire. Ils peuvent être tout aussi utile que de commentaires; de plus, parce que d'affirmations, ils réellement TESTER ce qu'ils document.

Les affirmations sont pour les tests et le débogage, pas de vérification des erreurs, c'est pourquoi ils sont désactivés par défaut: pour décourager les gens d'utiliser les assertions pour valider la saisie de l'utilisateur.

18voto

Bill the Lizard Points 147311

À partir de la Programmation avec les Affirmations

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

Cela signifie que si vous n'avez pas le contrôle complet de l'environnement d'exécution, vous ne pouvez pas garantir que l'affirmation de code va même être appelé. Les Assertions sont destinés à être utilisés dans un test-environnement, pas pour la production de code. Vous ne pouvez pas remplacer la gestion des exceptions avec les assertions si l'utilisateur exécute votre application avec les affirmations désactivé ( par défaut), tous de votre code de gestion d'erreur disparaît.

18voto

yclian Points 1040

Dans "Effective Java", Joshua Bloch suggéré (dans la section "Vérification des paramètres de validité") qui (comme une sorte de règle simple à adopter), pour les méthodes publiques, nous allons valider les arguments et les jeter exception nécessaire si l'invalide, et pour les non-public des méthodes (qui ne sont pas exposés, et l'utilisateur doivent s'assurer de leur validité), on peut utiliser l'affirmation de la place.

yc

9voto

akuhn Points 12241

@Don, vous êtes frustré cette affirmation sont désactivés par défaut. J'ai été également, et donc écrit ce petit javac plugin qui inlines (ie émet le pseudo-code d' if (!expr) throw Ex plutôt que cet idiot d'affirmer bytecode.

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

Note: %n assertions inlined.

@voir http://smallwiki.unibe.ch/adriankuhn/javacompiler/forceassertions

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X