Exception Et Assertion

Java assertions sont construits en plus de Java exceptions et traitement des exceptions. En effet, lorsqu'une assertion Java échoue, le résultat est une exception AssertionError qui peut être attrapée comme n'importe quelle autre exception Java. Les principales différences entre les exceptions et les affirmations sont les suivantes:

• Affirmations sont prévu pour être utilisées uniquement comme un moyen de détecter des erreurs de programmation, aka bugs. En revanche, une exception peut indiquer d'autres types de erreur ou condition "exceptionnelle"; par exemple entrée utilisateur invalide, fichiers manquants, tas plein et ainsi de suite.

• le langage Java fournit un support syntaxique pour les assertions, sous la forme de la déclaration assert . Comparez ce qui suit:

  if (x != y) {
       throw new SomeException("x != y");
  }
  
  assert x != y;
  

• le plus important, Java vous permet d'activer ou de désactiver la vérification d'assertions globalement ou sur des classes individuelles lorsque vous démarrez la JVM.

Note: certaines personnes disent que vous devriez toujours exécuter le code de production avec vérification assertion désactivée. J'ai tendance à ne pas être d'accord avec cette affirmation générale. Si votre code de production est connu pour être stable et vous avez besoin de presser ce dernier morceau de performance hors de lui, puis désactiver les assertions est bon. Mais, si un (disons) 10% de performance hit n'est pas un vrai problème, je préférerais avoir une application mourir avec une erreur d'assertion si l'alternative est continue et corrompu ma base de données.

@Mario Ortegón commente ainsi:

le "turning off" est parce que les assertions peuvent être utilisées pour vérifier le résultat d'un algorithme optimisé en comparant sa mise en œuvre avec un algorithme bien connu, mais lent. Ainsi, dans le développement, il est correct d'invoquer cette méthode O(N^3) pour affirmer que l'algorithme O(log N) fonctionne comme prévu. Mais c'est quelque chose que vous ne voulez pas dans la production.

Qu'il s'agisse ou non de bonne pratique désactiver les assertions en production, il est certain mauvaise pratique écrire des assertions qui ont un impact significatif sur la performance lorsqu'elles sont activées. Pourquoi? Parce que cela signifie que vous n'avez plus la possibilité de permettre des assertions en production (pour tracer un problème) ou dans vos tests de stress / capacité. À mon avis, si vous avez besoin de faire O(N^3) test pré/post-condition, vous devriez le faire dans vos tests unitaires.

Exception est un mécanisme de vérification si la mise en œuvre s'exécute sans aucune erreur attendue ou inattendue ou pas. Ainsi, nous voyons que les exceptions sont essentiellement utilisées pour traiter même les conditions imprévues pendant l'exécution d'une application d'une meilleure manière et donc en utilisant des exceptions se traduit effectivement dans une application robuste.

Assertions ne devraient jamais faire partie de la mise en œuvre d'une certaine fonctionnalité de l'application. Ils ne doivent être utilisé pour vérifier les hypothèses - juste pour être sûr que ce que nous avons supposé lors de la conception de la solution est effectivement valide dans la pratique aussi bien.

référence: http://geekexplains.blogspot.com/2008/06/asserions-in-java-assertions-vs.html

exemple de bonne utilisation D'Assert:

assert flibbles.count() < 1000000; // too many flibbles indicate something is awry
log.warning("flibble count reached " + flibbles.count()); // log in production as early warning

je pense personnellement que Assert devrait seulement être utilisé quand vous savez que quelque chose est en dehors de souhaitable limites, mais vous pouvez être sûr qu'il est raisonnablement sûr de continuer. Dans toutes les autres circonstances (n'hésitez pas à faire remarquer les circonstances auxquelles je n'ai pas pensé), utilisez des exceptions pour échouer rapidement et avec acharnement.

le compromis clé pour moi est si vous voulez démonter un système de production / live avec une Exception pour éviter la corruption et faciliter le dépannage, ou si vous avez rencontré une situation qui ne devrait jamais passer inaperçue dans les versions de test/debug mais pourrait être autorisé à continuer dans la production (journalisation d'un avertissement bien sûr).

cf. http://c2.com/cgi/wiki?FailFast voir aussi ma copie c# de cette réponse: Debug.Faire valoir contre des Exceptions précises

Assertions sont très similaires aux exceptions, en fait tout comme les exceptions, ils vont signaler un problème, mais contrairement aux exceptions - ils ne suggéreront pas de chemin d'exécution alternative, mais vont tout simplement échouer. Pourquoi utiliser des assertions, si vous pouvez faire la même chose, plus plus avec des exceptions ?

utilisez-les quand les problèmes ne devraient pas être résolus, et en fait ne devrait jamais se produire en premier lieu. Cela semble étrange au début: ne voulons - nous pas protéger notre code de tous les les problèmes potentiels ? En général, oui. Mais il y a un cas où nous ne le faisons pas. Ce cas est appelé: "Design by contract".

disons que vous écrivez une demande pour une banque. En tant que développeur, vous ne pouvez pas supporter toutes les conditions financières possibles. Ainsi, avant de commencer à coder, vous obtenez une spécification de la banque qui vous donne les gammes valides que cette application devrait soutenir. Si votre application est conçue par un contrat (par la spécification de la banque). Ce contrat de définir les principes fondamentaux qui devraient toujours être vrai pour que votre demande de travail. Ces principes fondamentaux sont appelés "invariants" (parce qu'ils ne peuvent pas changer). Design by contract simplifie votre vie en tant que développeur - vous n'êtes responsable que de la portée des travaux définis dans le contrat.

Il est important de vérifier les valeurs de ces invariants dans votre code, mais vous ne devriez pas les vérifier comme s'ils étaient des exceptions et essayer de travailler autour d'eux. S'ils sont faux - vous devez échouer parce que les intrants n'ont pas rempli leurs obligations contractuelles.

la chose intéressante est: si vous ne mettez pas une affirmation à la place critique et les invariants deviennent invalides - votre code échouera de toute façon. Vous juste ne sais pas pourquoi. Donc, pour résumer - assertions sont utilisés pour vérifier les invariants. Elles vont de pair avec le principe du" design by contract". Les utiliser pour déboguer un problème, c'est pourquoi ils sont désactivé dans la production.

un autre cas d'utilisation: si vous comptez sur une bibliothèque externe à laquelle vous ne faites pas entièrement confiance - vous pouvez utiliser des déclarations assert lorsque vous l'appelez.

certains utilisent aussi les assertions comme un substitut rapide et sale à une exception (puisque c'est si facile à faire), mais conceptuellement ce n'est pas la chose à faire.

Assert est uniquement destiné au débogage et sa condition de déclenchement ne devrait pas se produire (pointeur null quand il ne devrait pas y en avoir, etc.)

Exception pour les événements système spéciaux qui peuvent toujours se produire: FileNotFound, ConnectionToServerLost, etc.

"151900920 l'Assertion" la gestion des exceptions et les deux peuvent assurer le programme d'exactitude et d'éviter les erreur de logique,

mais assertion pouvez activer et désactiver en tant que programmeur souhaite,

dans le compilateur si vous utilisez "java-ea JavaFileName" ou " java-enableasserations JavaFileName" vous pouvez compiler avec assertion

si les programmeurs n'en ont pas besoin, " java-da JavaFileName "ou" java-disableasserations JavaFileName " ils peuvent désactiver l'assertion.

ce dispositif dans le traitement d'Exception

L'Assertion

est utilisée pour déboguer les hypothèses requises à vérifier à l'exécution seulement en activant la fonctionnalité assert alors que l'exception est de vérifier les conditions spécifiques à vérifier pendant l'exécution du programme pour empêcher le programme de se terminer.