Avoir des affirmations pour des conditions inattendues est considérée comme une bonne pratique de codage défensive. J'arrive à placer des affirmations chaque fois que je pense que quelque chose d'inattendu peut arriver, mais cela semble maintenant être une excédence pour moi.
En outre, des conditions inattendues parfois légères qui ne conduisent pas nécessairement à un crash peuvent même provoquer une défaillance de la fin du client.
Y a-t-il une règle difficile et rapide pour mettre des affirmations?
Merci.
5 Réponses :
Les assertions sont placées lorsque vous êtes très sûr que certaines conditions doivent être vraies avant d'aller au niveau suivant de votre code. Par exemple, lorsqu'une manche de fenêtre n'est pas valide ou lorsque certaines variables ne comportent pas de valeur valide.
Les sons de celui-ci, vous les laissez activé dans les constructions de version. Si tel est le cas, créez des niveaux d'assertions - ceux qui seront activés ou désactivés dans certaines constructions. Ensuite, utilisez simplement un niveau d'assertion.
De cette façon, vous n'avez pas besoin de les éteindre, de les éteindre ou de les supprimer pour le développement et la débogage des constructions ou des versions bêta.
Je les désactive généralement en libération, mais ils consomment une tonne de code écrit. Je ne pense pas que ce soit mauvais - il sert de documentation et applique l'interface à utiliser comme prévu. Je pense que c'est bien d'avoir ce que de nombreux Devs peuvent considérer trop d'affirmations, mais il n'y en a vraiment pas trop dans la grande image, car les codesbases évoluent et cela garantit que les programmes sont toujours utilisés comme prévu. Par conséquent, je ne vous recommande pas de les supprimer, il suffit de désactiver les contrôles non fatal des constructions de libération.
En fin de compte, il existe de meilleures approches que les niveaux (voir la discussion ci-dessous et prenez ce que vous voulez des réponses des autres) - mais les niveaux sont un moyen simple d'introduire considérablement le changement sans affecter considérablement les programmes existants. Ce serait une bonne approche pour une transition vers un autre schéma de traitement d'erreur, ou si vous êtes> 98% content de ce que vous avez déjà.
J'avais l'habitude de penser aux niveaux d'affirmations, mais il est très surprenant lorsqu'une erreur qui a été capturée dans le test n'est pas capturée dans la production. En outre, j'ai constaté que les développeurs ne savaient généralement pas quel niveau s'appliquent, et plus ou moins choisi en fonction de leur humeur ...
@Matthieu Great Points - Il est plus propre OMI d'utiliser un gestionnaire de condition mortelle désigné (et un message d'alerte ou de journal) si nécessaire et désactivez les affirmations de production. Bien entendu, cela dépend du ratio de l'OP des conditions d'erreur fatale et de la manière dont le code existant a été mis en œuvre. L'exception de mon code est gratuite dans la mesure du possible - les codes d'erreur / les états sont simplement poussés à l'appelant lorsqu'ils sont détectés ou rencontrés. Mais il peut s'agir d'un désordre de réécrire les programmes existants, alors j'ai suggéré des niveaux comme une solution qui n'aurait pas beaucoup d'impact sur le code existant.
Non, non, il n'y a pas ... Mais je recommanderais certainement le traitement des affirmations différemment dans le test et la production.
C'est parfaitement acceptable, dans un environnement de test, de produire un vidage de base. Il permet une inspection facile des conditions qui ont déclenché l'affirmation en conservant joliment de sécurité de l'état du programme.
Cependant, dans un environnement de production, vous ne voulez jamais planter (sauf en cas de corruption de mémoire ...). L'utilisateur s'attend à ce que le système répond toujours, il n'y a rien de plus irritant qui demande quelque chose et ne jamais recevoir de réponse. Par conséquent, c'est votre travail de vous assurer que l'utilisateur reçoit la réponse plus significative possible, même s'il s'agit d'un message d'erreur. Le moyen le plus simple d'y parvenir est généralement de lancer une exception.
Où mettre des affirmations?
Ce qui est souvent négligé, c'est qu'un assert peut également servir d'aide à la documentation.
Alors, ne testez pas seulement les «inattendus», utilisez-les également pour exprimer vos hypothèses (invariants) aux points critiques de votre code. Comme
assert (haut> = faible)et bien sûr les rendre conditionnels, car d'autres ont souligné ici.
La principale différence entre quand utiliser des assertions et des exceptions:
Utilisez une affirmation pour attraper des erreurs de programmation. Les assertions ne devraient jamais arriver si le code a été écrit correctement.
Utilisez des exceptions pour attraper des erreurs de temps d'exécution causées par un environnement inattendu.
Si votre programme lit un script ou un contenu à partir d'un fichier et qu'ils ne correspondent pas au format attendu, je considère que c'est une condition d'exécution donc une exception.
Vous pouvez décider, à des fins de débogage, d'utiliser une affirmation à la place où une exception est lancée simplement pour pouvoir s'entraîner plus facilement où elle a été lancée, bien que vous puissiez utiliser des macros exceptionnelles qui insérer