Assertions
Mise à jour : novembre 2007
Cette rubrique s'applique à :
Édition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif) |
|
Natif uniquement |
|
Standard |
|
|
Natif uniquement |
|
Pro et Team |
|
|
Natif uniquement |
|
Légende du tableau :
.gif) |
Applicable |
|
Non applicable |
.gif) |
Commande ou commandes masquées par défaut. |
Une instruction d'assertion spécifie une condition dont vous prévoyez qu'elle est vraie en un certain point de votre programme. Si cette condition n'est pas vraie, l'assertion échoue, l'exécution de votre programme est interrompue et la boîte de dialogue Échec de l'assertion apparaît.
Visual C++ accepte les instructions d'assertion basées sur les structures suivantes :
assertions MFC pour un programme MFC ;
ATLASSERT pour les programmes qui utilisent ATL ;
assertions CRT pour les programmes qui utilisent la bibliothèque Runtime C ;
la fonction d'assertion ANSI pour les autres programmes C/C++.
Vous pouvez utiliser des assertions pour :
Intercepter les erreurs de logique. Pour plus d'informations, consultez Interception des erreurs de logique.
Vérifier les résultats d'une opération. Pour plus d'informations, consultez Contrôle des résultats.
Tester les conditions d'erreur qui devraient avoir été gérées. Pour plus d'informations, consultez Test des conditions d'erreur.
Assertions de la bibliothèque Runtime C et MFC
Lorsque le débogueur s'arrête en raison d'une assertion de la bibliothèque MFC ou Runtime C, il navigue jusqu'au point du fichier source où l'assertion a eu lieu (si la source est disponible). Le message d'assertion apparaît dans la fenêtre Sortie, ainsi que dans la boîte de dialogue Échec d'assertion. Vous pouvez copier le message d'assertion de la fenêtre Sortie dans une fenêtre texte si vous souhaitez l'enregistrer pour vous y référer ultérieurement. La fenêtre Sortie peut également contenir d'autres messages d'erreur. Examinez attentivement ces messages, car ils fournissent des indications sur la cause de l'échec de l'assertion.
L'utilisation fréquente d'assertions dans votre code vous permet d'intercepter de nombreuses erreurs pendant le développement. Une excellente règle consiste à écrire une assertion pour chacune de vos hypothèses. Si vous supposez qu'un argument n'est pas NULL, par exemple, utilisez une instruction d'assertion pour vérifier cette hypothèse.
_DEBUG
Les instructions d'assertion sont compilées uniquement lorsque _DEBUG est défini. Si _DEBUG n'est pas défini, le compilateur traite les assertions comme des instructions null. Par conséquent, les instructions d'assertion ont une charge mémoire nulle dans la version Release finale de votre programme ; vous pouvez y recourir largement dans votre code sans entraver les performances de votre version Release et sans avoir à utiliser des directives #ifdef.
Effets secondaires de l'utilisation d'assertions
Lorsque vous ajoutez des assertions à votre code, assurez-vous qu'elles n'ont pas d'effets secondaires. Observez, par exemple, l'assertion suivante :
ASSERT(nM++ > 0); // Don't do this!
Dans la mesure où l'expression ASSERT n'est pas évaluée dans la version Release de votre programme, nM aura des valeurs différentes dans les versions Debug et Release. Dans les MFC, vous pouvez utiliser la macro VERIFY à la place de la macro ASSERT. VERIFY évalue l'expression, mais ne vérifie pas le résultat dans la version Release.
Soyez particulièrement vigilant avec les appels aux fonctions à l'intérieur des instructions d'assertion ; l'évaluation d'une fonction peut avoir des effets secondaires inattendus.
ASSERT ( myFnctn(0)==1 ) // unsafe if myFnctn has side effects
VERIFY ( myFnctn(0)==1 ) // safe
VERIFY appelle myFnctn dans les versions Debug et Release. Vous pouvez donc l'utiliser. Toutefois, vous aurez toujours le temps système d'un appel à une fonction superflue dans la version Release.
Voir aussi
Concepts
Référence
Assertions dans du code managé