Quand les assertions doivent-elles rester dans le code de production? [fermé]

166

Il y a une discussion en cours sur comp.lang.c ++. Modérée sur la question de savoir si les assertions, qui en C ++ n'existent que dans les versions de débogage par défaut, doivent être conservées ou non dans le code de production.

Évidemment, chaque projet est unique, donc ma question ici n'est pas tant de savoir si les affirmations doivent être conservées, mais dans quels cas c'est recommandable / pas une bonne idée.

Par assertion, je veux dire:

Un contrôle d'exécution qui teste une condition qui, lorsqu'elle est fausse, révèle un bogue dans le logiciel.
Un mécanisme par lequel le programme est arrêté (peut-être après un travail de nettoyage vraiment minime).

Je ne parle pas nécessairement de C ou C ++.

Ma propre opinion est que si vous êtes le programmeur, mais que vous ne possédez pas les données (ce qui est le cas avec la plupart des applications de bureau commerciales), vous devriez les garder, car une asssertion défaillante montre un bogue, et vous ne devriez pas y aller avec un bug, avec le risque de corrompre les données de l'utilisateur. Cela vous oblige à tester fortement avant de livrer, et rend les bogues plus visibles, donc plus faciles à repérer et à corriger.

Quelle est votre opinion / expérience?

À votre santé,

Carl

Voir la question associée ici

Réponses et mises à jour

Salut Graham,

Une assertion est une erreur pure et simple et doit donc être traitée comme telle. Puisqu'une erreur doit être gérée en mode version, vous n'avez pas vraiment besoin d'assertions.

C'est pourquoi je préfère le mot «bug» quand je parle d'assertions. Cela rend les choses beaucoup plus claires. Pour moi, le mot «erreur» est trop vague. Un fichier manquant est une erreur, pas un bogue, et le programme doit y remédier. Essayer de déréférencer un pointeur nul est un bogue, et le programme devrait reconnaître que quelque chose sent le mauvais fromage.

Par conséquent, vous devez tester le pointeur avec une assertion, mais la présence du fichier avec un code normal de gestion des erreurs.

Légèrement hors sujet, mais un point important dans la discussion.

En guise d'avertissement, si vos assertions pénètrent dans le débogueur lorsqu'elles échouent, pourquoi pas. Mais il y a de nombreuses raisons pour lesquelles un fichier ne pourrait pas exister qui sont complètement hors du contrôle de votre code: droits de lecture / écriture, disque plein, périphérique USB débranché, etc. Comme vous n'en avez pas le contrôle, je pense que les affirmations sont ce n'est pas la bonne façon de traiter cela.

Carl

Thomas,

Oui, j'ai Code Complete et je dois dire que je ne suis pas du tout d'accord avec ce conseil particulier.

Supposons que votre allocateur de mémoire personnalisé se trompe et remette à zéro un morceau de mémoire qui est encore utilisé par un autre objet. Il m'arrive de mettre à zéro un pointeur que cet objet déréférence régulièrement, et l'un des invariants est que ce pointeur n'est jamais nul, et vous avez quelques assertions pour vous assurer qu'il reste ainsi. Que faire si le pointeur est soudainement nul. Vous juste si () autour de lui, en espérant que cela fonctionne?

N'oubliez pas que nous parlons de code produit ici, il n'y a donc pas de rupture dans le débogueur et d'inspection de l'état local. C'est un vrai bug sur la machine de l'utilisateur.

Carl

assert

— inconnus
source

3

Il y a un article connexe intéressant au Software Engineering SE (bien que la discussion soit centrée sur le c ++): Devrait-il y avoir des affirmations dans les versions de version

— sonny

84

Les assertions sont des commentaires qui ne deviennent pas obsolètes. Ils documentent quels états théoriques sont prévus et quels états ne devraient pas se produire. Si le code est modifié afin que les états soient autorisés à changer, le développeur est rapidement informé et doit mettre à jour l'assertion.

— MSalters
source

16

@jkschneider: les tests unitaires sont pour tester des choses dans le cadre du code du programme. les assertions sont destinées à garantir que les hypothèses sur lesquelles le code est basé sont réellement vraies dans la réalité, avant que le code ne continue le traitement selon ces hypothèses. Ce sont de la "documentation" dans le sens où, si elles s'avèrent ne pas être le cas, le programme abandonnera, énonce l'hypothèse et indique que l'hypothèse ne tient pas. Vous pouvez également lire l'assertion comme documentation de cela dans le code, bien sûr.

2

C'est la meilleure réponse car elle relie les affirmations aux commentaires, ce qui est une manière utile de les considérer. Ils sont un pas en avant par rapport aux commentaires car ils sont constamment testés par machine pendant le développement, mais ils devraient toujours avoir un sens pour les lecteurs humains en premier. Tout comme les commentaires, ils ne doivent pas faire partie de la logique ou de l'exécution finale. Tout comme les commentaires, vous pouvez les laisser ou les supprimer selon que le langage est compilé ou interprété, vos plans de déploiement, votre stratégie d'obscurcissement, etc. J'ai vu un cas où un commentaire a effectivement causé un bogue, mais c'était un étrange.

— DaveWalley

1

Plus spécifiquement, les affirmations sont informatives et non fonctionnelles . Une assertion en elle-même n'a aucun effet sur le déroulement ou les résultats du programme. Une exception, en revanche, modifie le déroulement du programme et donc les résultats.

— yoyo

59

Permettez-moi de citer le code complet de Steve McConnell. La section sur les assertions est 8.2.

Normalement, vous ne voulez pas que les utilisateurs voient les messages d'assertion dans le code de production; les affirmations sont principalement destinées à être utilisées pendant le développement et la maintenance. Les assertions sont normalement compilées dans le code au moment du développement et compilées hors du code pour la production.

Cependant, plus loin dans la même section, ce conseil est donné:

Pour un code très robuste, affirmez et gérez quand même l'erreur.

Je pense que tant que les performances ne sont pas un problème, laissez l'assertion, mais plutôt que d'afficher un message, faites-la écrire dans un fichier journal. Je pense que ce conseil est également dans Code Complete, mais je ne le trouve pas pour le moment.

— Thomas Owens
source

7

Je pense que ce que signifie la deuxième citation de Code Complete, c'est que vous devriez avoir l'assert - qui sera compilé dans le code de production - et vous devriez également avoir "if (! Condition) {AttemptGracefulRecovery ();}", c'est-à-dire don ne laissez pas la violation des invariants du programme bloquer le programme.

— yoyo

34

Laissez les assertions activées dans le code de production, sauf si vous avez mesuré que le programme s'exécute beaucoup plus rapidement avec elles désactivées.

si cela ne vaut pas la peine de mesurer pour prouver qu'il est plus efficace, alors il ne vaut pas la peine de sacrifier la clarté pour un pari de performance. "- Steve McConnell 1993

http://c2.com/cgi/wiki?ShipWithAssertionsOn

— David Cary
source

11

En fait, la pire chose qui arrive est lorsque le code plante en raison de quelque chose qui n'est PAS une assertion. Si le code tombe définitivement en panne plus tard avec une probabilité de 100%, alors l'assertion doit absolument être là. Si vous déréférez un pointeur, vous devez affirmer implicitement qu'il n'est pas nul auparavant. Si vous divisez par un nombre, vous affirmez que ce n'est pas zéro. Supprimez les affirmations et tous les emplacements de crash ne sont PAS DOCUMENTÉS. Le vrai problème n'est pas de structurer le programme pour laisser les sous-systèmes planter et être redémarrés par un chien de garde.

— Rob

5

assert ref != null;est différent de if (ref == null) throw new IllegalArgumentException();Vous ne devriez pas utiliser le premier pour des conditions préalables qui pourraient être fausses. Vous devez utiliser assertpour des choses qui ne peuvent pas être fausses. Exemple, int i = -1 * someNumber; i = i * i;puis plus tard pour rappeler aux gens que ic'est positif,assert i > 0;

— Captain Man

1

"En fait, la pire chose qui arrive est lorsque le code plante en raison de quelque chose qui n'est PAS une assert. Si le code va définitivement planter plus tard avec une probabilité de 100%, alors l'assert doit absolument être là." - C'est une fausse dichotomie.

— Rob Grant

2

@RobertGrant: Pour de nombreux programmes, le plantage est loin d'être la pire chose qui puisse arriver. Pour un programme censé vérifier la solidité d'un bâtiment ou d'une conception de pont, signaler à tort qu'une conception est saine peut être à peu près la pire chose qu'il puisse faire. Pour un programme qui est exposé au monde extérieur mais qui a un accès en lecture seule à des données confidentielles, la fuite de ces données peut être pire que tout ce que le programme pourrait faire. L'idée qu'un accident sans indication significative de la cause est «la pire chose qui puisse arriver» ignore de nombreux dangers qui sont bien pires.

— supercat le

@supercat Je n'étais pas d'accord avec le commentaire que je citais.

— Rob Grant le

21

Si vous envisagez même de laisser des affirmations en production, vous y pensez probablement mal. L'intérêt des affirmations est que vous pouvez les désactiver en production, car ils ne font pas partie de votre solution. Il s'agit d'un outil de développement, utilisé pour vérifier que vos hypothèses sont correctes. Mais au moment où vous entrez en production, vous devriez déjà avoir confiance en vos hypothèses.

Cela dit, il y a un cas où je vais activer les assertions en production: si nous rencontrons un bogue reproductible en production que nous avons du mal à reproduire dans un environnement de test, il peut être utile de reproduire le bogue avec les assertions activées en production, pour voir si elles fournissent des informations utiles.

Une question plus intéressante est la suivante: dans votre phase de test, quand désactivez-vous les assertions?

— MiguelMunoz
source

4

Je pense que les assertions ne devraient jamais être incluses dans le code de production. les assertions ne sont PAS des erreurs, elles sont conçues pour les développeurs. Les assertions ne doivent vivre que dans le code de test. Avoir un plantage d'application est dû à un développement inacceptable et bâclé. Les développeurs doivent faire un effort supplémentaire pour gérer les erreurs avec élégance.

— iksnae

9

S'il est inévitable que vous vous plantiez étant donné un pointeur nul passé dans un fn; il n'y a pas le choix de le traiter explicitement. Soit vous avez un moyen de gérer la condition avec élégance (car elle peut provenir d'une entrée du monde extérieur), soit vous vous plantez à un emplacement DOCUMENTÉ avec une assertion, plutôt qu'à un endroit aléatoire qui peut avoir corrompu des choses en cours de route. La manière dont l'assertion est gérée doit cependant être une décision par module. Peut-être que votre chien de garde redémarre le processus, ou vous effacez une partie de la mémoire de ce module pour le réinitialiser à l'état de démarrage (objet logiciel «redémarrage»).

— Rob

1

Je pense que c'est une vision limitée de l'utilisation des affirmations. J'enregistre toujours les assertions à la fois sur la console et le stockage cloud, et je les laisse en production. Laisser des affirmations sur confirme que mes hypothèses restent correctes même dans le code de production et dans l'utilisation de la production. Ce n'est pas parce que le code s'est exécuté plusieurs fois avec succès dans le débogage avec des assertions activées que les utilisateurs ne trouveront pas un moyen de transmettre différentes valeurs via le même chemin de code.

— SafeFastExpressive

L'intérêt de l'instruction assert est que vous pouvez activer ou désactiver les vérifications. Si vous les laissez en production, pourquoi utiliser l'instruction assert?

— MiguelMunoz

1

Les affirmations ralentissent souvent le système. Comme ils ne sont pas conçus pour la production, ils sont libres d'être lents et inefficaces, ce qui peut être nécessaire pour effectuer certains tests. Par exemple, Microsoft a ajouté une fois une fonction de recalcul rapide à Excel. Lorsqu'une cellule changeait, cette fonction limitait le recalcul aux seules cellules qui en avaient besoin. Ils ont testé cela avec une assertion qui a recalculé l'ensemble de la feuille de calcul et comparé les résultats. Cela a rendu la version de développement très lente, mais a également éliminé de nombreux bogues. Quand ils ont sorti cette fonctionnalité, elle s'est avérée très fiable.

— MiguelMunoz

16

Les assertions ne doivent jamais rester dans le code de production. Si une assertion particulière semble utile dans le code de production, elle ne doit pas être une assertion; il devrait être un contrôle d'erreur de temps d'exécution, à savoir quelque chose à code comme ceci: if( condition != expected ) throw exception.

Le terme «assertion» en est venu à signifier «une vérification uniquement au moment du développement qui ne sera pas effectuée sur le terrain».

Si vous commencez à penser que des affirmations pourraient arriver sur le terrain, vous commencerez inévitablement à faire d'autres pensées dangereuses, comme vous demander si une affirmation donnée vaut vraiment la peine d'être faite. Il n'y a aucune affirmation qui ne vaille la peine d'être faite. Vous ne devriez jamais vous demander "devrais-je affirmer cela ou non?" Vous devriez seulement vous demander "Y a-t-il quelque chose que j'ai oublié d'affirmer?"

— Mike Nakis
source

6

À moins que le profilage montre que les assertions causent des problèmes de performances, je dis qu'elles devraient également rester dans la version de production.

Cependant, je pense que cela nécessite également que vous gériez les échecs d'assertion avec une certaine élégance. Par exemple, ils devraient aboutir à un type général de dialogue avec l'option de signaler (automatiquement) le problème aux développeurs, et pas seulement de quitter ou de planter le programme. En outre, vous devez faire attention à ne pas utiliser d'assertions pour des conditions que vous autorisez réellement, mais que vous n'aimez peut-être pas ou ne considérez pas comme indésirables. Ces conditions doivent être gérées par d'autres parties du code.

— Anders Sandvig
source

À mon avis, le principal objectif d'une affirmation de production est de servir de filet de sécurité d'urgence: permettre au programme de se poursuivre est très susceptible de causer un préjudice suffisamment grave pour que la prévention soit plus importante que tout ce que le programme pourrait faire. Avoir un bon message d'erreur serait bien, si possible, mais ce n'est que secondaire.

— supercat le

5

Dans mon C ++, je définis REQUIRE (x) qui est comme assert (x) sauf qu'il lève une exception si l'assertion échoue dans une version de version.

Puisqu'une assertion échouée indique un bogue, elle doit être traitée sérieusement même dans une version Release. Lorsque les performances de mon code sont importantes, j'utiliserai souvent REQUIRE () pour le code de niveau supérieur et assert () pour le code de niveau inférieur qui doit s'exécuter rapidement. J'utilise également REQUIRE au lieu d'affirmer si la condition d'échec peut être causée par des données transmises à partir d'un code écrit par un tiers, ou par une corruption de fichier (de manière optimale, je concevoirais le code spécifiquement pour qu'il se comporte bien en cas de corruption de fichier, mais nous n’a pas toujours le temps de faire ça.)

Ils disent que vous ne devriez pas montrer ces messages d'affirmation aux utilisateurs finaux parce qu'ils ne les comprendront pas. Alors? Les utilisateurs finaux peuvent vous envoyer un e-mail avec une capture d'écran ou du texte du message d'erreur, ce qui vous aide à déboguer. Si l'utilisateur dit simplement "il s'est écrasé", vous avez moins de capacité à le réparer. Il serait préférable de vous envoyer automatiquement les messages d'échec d'assertion sur Internet, mais cela ne fonctionne que si l'utilisateur a accès à Internet et que vous pouvez obtenir sa permission.

— Qwertie
source

Ils disent également que vous ne devriez pas montrer ces messages d'affirmation aux pirates, car ce sont des indices précieux pour effraction.

— DaveWalley

4

Si vous souhaitez les conserver, remplacez-les par une gestion des erreurs. Rien de pire qu'un programme en train de disparaître. Je ne vois rien de mal à traiter certaines erreurs comme des bogues graves, mais elles devraient être dirigées vers une section de votre programme qui est équipée pour les traiter en collectant des données, en les enregistrant et en informant l'utilisateur que votre application a eu une condition indésirable et sort.

— bruceatk
source

2

À condition qu'ils soient traités comme toute autre erreur, je ne vois pas de problème avec cela. Gardez à l'esprit que les assertions ratées en C, comme avec d'autres langages, vont simplement quitter le programme, et ce n'est généralement pas suffisant pour les systèmes de production.

Il y a quelques exceptions - PHP, par exemple, vous permet de créer un gestionnaire personnalisé pour les échecs d'assertion afin que vous puissiez afficher les erreurs personnalisées, effectuer une journalisation détaillée, etc. au lieu de simplement quitter.

— Steve M
source

2

Notre logiciel de serveur de base de données contient à la fois des assertions de production et de débogage. Les assertions de débogage ne sont que cela - elles sont supprimées dans le code de production. Les assertions de production ne se produisent que si (a) une condition existe qui devrait ne jamais exister et (b) il n'est pas possible de récupérer de manière fiable de cette condition. Une assertion de production indique qu'un bogue dans le logiciel a été rencontré ou qu'une sorte de corruption de données s'est produite.

Puisqu'il s'agit d'un système de base de données et que nous stockons des données potentiellement critiques pour l'entreprise, nous faisons tout notre possible pour éviter les données corrompues. Si une condition existe peut nous amener à stocker des données incorrectes, nous affirmons immédiatement, annulons toutes les transactions et arrêtons le serveur.

Cela dit, nous essayons également d'éviter les assertions de production dans les routines critiques pour les performances.

— Graeme Perrow
source

5

J'appellerais votre "assertion de production" une "exception", et je la coderais comme telle.

— DaveWalley

1

Vous avez probablement raison, mais le produit a été initialement écrit en C. Même lorsque nous l'avons changé en C ++, les compilateurs que nous avons utilisés sur certaines de nos plates-formes ne supportaient pas correctement les exceptions. La plupart de l'ancien code n'a pas été réécrit en C ++, donc ces assertions sont toujours utilisées.

— Graeme Perrow

1

Je vois les assertions comme des tests unitaires en ligne. Utile pour un test rapide lors du développement, mais finalement ces assertions doivent être refactorisées pour être testées en externe dans des tests unitaires.

— Weston
source

Affirmer: énoncer un fait ou une croyance. Ils ne sont pas pour tester (seulement), mais pour indiquer ce que vous pensez être vrai (c'est-à-dire vos hypothèses), afin que votre programme ne continue pas si vos hypothèses sont fausses pour une raison quelconque. Par exemple, il s'agit d'une utilisation valide des assertions: assert (pow (1,0) <1). Ce n'est pas vraiment un endroit approprié pour la vérification des erreurs, car si ce n'est pas vrai, alors presque toutes les mathématiques modernes sont erronées, et ... eh bien, comment commenceriez-vous même à gérer cela? Le traitement de cette hypothèse incorrecte sort du cadre du programme; vous le prenez par foi. Mais vous vérifiez, de toute façon.

1

Je trouve qu'il est préférable de gérer toutes les erreurs qui sont dans la portée et d'utiliser des assertions pour les hypothèses que nous affirmons sont vraies.

c'est-à-dire que si votre programme ouvre / lit / ferme un fichier, alors ne pas pouvoir ouvrir le fichier est dans la portée - c'est une possibilité réelle, qu'il serait négligent d'ignorer, en d'autres termes. Donc, cela devrait avoir un code de vérification des erreurs associé.

Cependant, disons que votre fopen () est documentée comme renvoyant toujours un handle de fichier valide et ouvert. Vous ouvrez le fichier et le transmettez à votre fonction readfile ().

Cette fonction readfile, dans ce contexte, et probablement selon ses spécifications de conception, peut à peu près supposer qu'elle va obtenir un fichier valide ptr. Il serait donc inutile d'ajouter du code de gestion des erreurs pour le cas négatif, dans un programme aussi simple. Cependant, il devrait au moins documenter l'hypothèse, d'une manière ou d'une autre - assurer d'une manière ou d'une autre - que c'est effectivement le cas, avant de continuer son exécution. Il ne doit pas VRAIMENT supposer que ce sera toujours valide, au cas où il est appelé de manière incorrecte, ou s'il est copié / collé dans un autre programme, par exemple.

Donc, readfile () {assert (fptr! = NULL); ..} est approprié dans ce cas, alors que la gestion complète des erreurs ne l'est pas (en ignorant le fait que la lecture réelle du fichier nécessiterait de toute façon un système de gestion des erreurs).

Et oui, ces affirmations devraient rester dans le code de production, à moins qu'il ne soit absolument nécessaire de les désactiver. Même dans ce cas, vous ne devriez probablement les désactiver que dans les sections critiques pour les performances.

— Lee
source

1

Supposons qu'un morceau de code soit en production et qu'il atteigne une assertion qui serait normalement déclenchée. L'assertion a trouvé un bug! Sauf que ce n'est pas le cas, car l'assertion est désactivée.

Qu'est-ce-qu'on fait maintenant? Soit le programme (1) plantera de manière non informative à un point plus éloigné de la source du problème, soit (2) fonctionnera joyeusement jusqu'à la fin, donnant probablement un résultat erroné.

Aucun des deux scénarios n'est invitant. Laisser les assertions actives même en production.

— Marmotte tueuse
source

0

J'utilise rarement des assertions pour autre chose que la vérification de type à la compilation. J'utiliserais une exception au lieu d'une assertion simplement parce que la plupart des langages sont conçus pour les gérer.

Je donne un exemple

file = create-some-file();
_throwExceptionIf( file.exists() == false, "FILE DOES NOT EXIST");

contre

file = create-some-file();
ASSERT(file.exists());

Comment l'application traiterait-elle l'assertion? Je préfère l'ancienne try catchméthode pour traiter les erreurs fatales.

— roo
source

2

Les exceptions concernent les situations inhabituelles que vous prévoyez de rencontrer dans une application en cours de fonctionnement, comme dans votre exemple ici. Les affirmations concernent des situations que vous vous attendez à ne jamais rencontrer. Donc, si vous les rencontrez, il doit y avoir un bogue dans votre code. Dans votre exemple, et l'exception est clairement la bonne approche. Mais les assertions sont toujours très utiles pour attraper les bugs.

— MiguelMunoz

0

La plupart du temps, lorsque j'utilise l'assertion en java (le mot-clé assert), j'ajoute automatiquement des codes de production après. Selon le cas, cela peut être un message de journalisation, une exception ... ou rien.

Selon moi, toutes vos affirmations sont essentielles dans la version de développement, pas dans la version de production. Certains d'entre eux doivent être conservés, d'autres doivent être jetés.

— Nicolas
source

0

Les ASSERTIONS ne sont pas des erreurs et ne doivent pas être traitées comme des erreurs. Lorsqu'une assertion est lancée, cela signifie qu'il y a un bogue dans votre code ou alternativement dans le code appelant votre code.

Il y a quelques points pour éviter d'activer les assertions dans le code de production: 1. Vous ne voulez pas que votre utilisateur final voie un message comme "ASSERTION failed MyPrivateClass.cpp line 147. L'utilisateur final n'est PAS votre ingénieur QA. 2. ASSERTION pourrait influencer la performance

Cependant, il y a une bonne raison de laisser des affirmations: ASSERTION peut influencer les performances et le timing, et malheureusement cela a parfois de l'importance (en particulier dans les systèmes embarqués).

J'ai tendance à voter pour laisser l'assertion activée dans le code de production, mais en m'assurant que ces impressions ne sont pas exposées à l'utilisateur final.

~ Yitzik

— Yitshak Yarom
source

Non, les affirmations sont pour des faits supposés. Si notre code renvoie 27 alors qu'il est supposé qu'il retournera TOUJOURS 25, le problème pourrait aussi être un bogue dans nos hypothèses physiques sur l'univers: peut-être que ces deux bits sont passés à la valeur 5 possible, pour la première fois dans l'histoire de l'informatique. L'assertion est là pour confirmer que votre code fonctionne toujours sous les hypothèses pour lesquelles il a été écrit. Si la physique sort par la fenêtre, votre code devrait le remarquer, laissez le lecteur seul et quittez pendant qu'il avance;) Mais oui, ce n'est pas une erreur dans le code, et quel type de gestion des erreurs pouvez-vous faire?

Permettez-moi d'affiner mon opinion: 1. L'affirmation vérifie nos hypothèses. Si nos hypothèses sont fausses, cela signifie qu'il y a un bogue dans NOTRE code. 2. Notre code ne doit pas affirmer l'utilisation de notre code. c'est-à-dire qu'une fonction ne doit pas échouer lors d'une assertion si quelque chose ne va pas dans l'entrée de l'utilisateur. Nous retournerons l'erreur et l'utilisateur devrait gérer (il peut affirmer le succès) 3. Je préfère laisser l'assertion en production - mais le comportement sera probablement modifié. Je reconnais qu'il n'y a pas de gestion des erreurs appropriée. Échec de l'assertion == bug .. mais le système pourrait se réinitialiser au lieu de s'arrêter et d'attendre le redémarrage.

— Yitshak Yarom du

1

cela ne signifie pas NÉCESSAIREMENT qu'il y a un bogue. Par exemple, de nombreux projets dans lesquels je suis impliqué sont accompagnés d'une liste de faits supposés dans la documentation. Ces hypothèses sont là pour éviter que le code des développeurs ne soit appelé bogué, lorsque les gens d'affaires leur ont peut-être dit la mauvaise chose, ou lorsqu'aucune information n'est disponible de tiers sur des variables particulières, par exemple. Les assertions peuvent être utilisées pour vérifier que le programme doit / ne doit pas s'exécuter, que les systèmes tiers sont corrects, pas seulement si l'informatique est correcte.

-8

Une assertion est une erreur pure et simple et doit donc être traitée comme telle.

Puisqu'une erreur doit être gérée en mode version, vous n'avez pas vraiment besoin d'assertions.

Le principal avantage que je vois pour les assertions est une rupture conditionnelle - elles sont beaucoup plus faciles à configurer que de parcourir les fenêtres de VC pour configurer quelque chose qui prend 1 ligne de code.

— graham.reeds
source

2

Utiliser des assertions comme points d'arrêt conditionnels est vraiment ennuyeux pour plusieurs raisons. Le plus important est que ces affirmations déroutent les autres développeurs de l'équipe - comment sauraient-ils s'il s'agit d'une erreur lorsque cette affirmation est déclenchée ou est-ce que quelqu'un a laissé son point d'arrêt conditionnel dans le code?

— lego

Il n'y en aurait pas si les assertions n'étaient pas dans le code en premier lieu. Et si vous les utilisiez uniquement pour surveiller le code, vous les verriez (à moins que vous ne les archiviez dans l'arborescence des sources). J'ai travaillé dans des endroits qui ont des affirmations pour pratiquement tout. Le fait de devoir cliquer environ 60 fois au démarrage du programme car le serveur de documentation d'aide n'est pas disponible devient très vite fastidieux.

— graham.reeds