Assertions dans du code managé

Article
08/21/2008

Mise à jour : novembre 2007

Cette rubrique s'applique à :

Édition	Visual Basic	C#	C++	Web Developer
Express
Standard
Pro et Team

Légende du tableau :

	Applicable
	Non applicable
	Commande ou commandes masquées par défaut.

Une assertion, ou instruction Assert, teste une condition, que vous spécifiez en tant qu'argument à l'instruction Assert. Si la condition a la valeur true, aucune action ne se produit. Si la condition a la valeur false, l'assertion échoue. S'il est exécuté avec une version Debug, votre programme passe en mode arrêt.

En Visual Basic et Visual C#, vous pouvez utiliser la méthode Assert de Debug ou Trace, qui se trouve dans l'espace de noms System.Diagnostics. Les méthodes de classe Debug n'étant pas comprises dans une version Release de votre programme, elles n'augmentent pas la taille ou elles réduisent la vitesse de votre code de version finale.

C++ ne prend pas en charge les méthodes de classe Debug. Vous pouvez accomplir le même effet grâce à la classe Trace avec compilation conditionnelle, telle que #ifdef DEBUG... #endif.

Debug.Assert, méthode

Utilisez librement la méthode Debug.Assert pour tester les conditions qui doivent avoir la valeur true si votre code est correct. Par exemple, si vous avez écrit une fonction de division d'entier. Selon les règles mathématiques, le diviseur ne peut pas être égal à zéro. Vous pouvez tester cela en utilisant une assertion :

[Visual Basic]

Function IntegerDivide(ByVal dividend As Integer, ByVal divisor As Integer) As Integer
    Debug.Assert(divisor <> 0)
    Return CInt(dividend / divisor)
End Function

[C#]

int IntegerDivide ( int dividend , int divisor )
    { Debug.Assert ( divisor != 0 );
        return ( dividend / divisor ); }

Lorsque vous exécutez ce code sous le débogueur, l'instruction d'assertion est évaluée, mais dans la version Release, la comparaison n'est pas faite, donc il n'y a pas de charge mémoire supplémentaire.

Voici un autre exemple. Vous avez une classe qui implémente un compte courant de la manière suivante :

[Visual Basic]

Dim amount, balance As Double
balance = savingsAccount.balance
Debug.Assert(amount <= balance)
SavingsAccount.Withdraw(amount)

[C#]

float balance = savingsAccount.Balance;
Debug.Assert ( amount <= balance );
savingsAccount.Withdraw ( amount );

Avant de retirer de l'argent du compte, vous voulez vous assurer que le crédit de votre compte est suffisant pour couvrir la somme que vous allez retirer. Vous pouvez écrire une assertion pour contrôler le solde :

[Visual Basic]

Dim amount, balance As Double
balance = savingsAccount.balance
Trace.Assert(amount <= balance)
SavingsAccount.Withdraw(amount)

[C#]

float balance = savingsAccount.Balance;
Trace.Assert ( amount <= balance );
savingsAccount.Withdraw ( amount );

Notez que les appels à la méthode Debug.Assert disparaissent lorsque vous créez une version Release de votre code. Cela signifie que l'appel qui vérifie l'équilibre disparaît dans la version Release. Pour résoudre ce problème, remplacez Debug.Assert par Trace.Assert, qui ne disparaît pas dans la version Release :

Les appels à Trace.Assert, contrairement aux appels à Debug.Assert, ajoutent une charge mémoire à la version Release.

Effets secondaires de Debug.Assert

Lorsque vous utilisez Debug.Assert, veillez à ce qu'aucun code dans Assert ne change les résultats du programme si Assert est supprimé. Sinon, vous pouvez par accident introduire un bogue qui ne se produira que dans la version Release de votre programme. Soyez particulièrement vigilant avec les instructions Assert qui contiennent des appels de fonction ou de procédure, comme par exemple dans l'exemple suivant :

[Visual Basic]

' unsafe code
Debug.Assert (meas(i) <> 0 )

[C#]

// unsafe code
Debug.Assert (meas(i) != 0 );

Cette utilisation de Debug.Assert peut sembler sûre à première vue, mais supposons que la fonction meas mette à jour un compteur à chaque fois qu'elle est appelée. Lorsque vous générez la version Release, cet appel à meas est éliminé, et le compteur ne sera pas mis à jour. Il s'agit d'un exemple d'une fonction avec un effet secondaire. L'élimination d'un appel à une fonction qui a un effet secondaire peut générer un bogue qui n'apparaît que dans la version Release. Pour éviter ce genre de problèmes, ne placez pas d'appels de fonction dans une instruction Debug.Assert. Utilisez une variable temporaire à la place :

[Visual Basic]

temp = meas( i )
Debug.Assert (temp <> 0)

[C#]

temp = meas( i );
Debug.Assert ( temp != 0 );

Même lorsque vous utilisez Trace.Assert, vous pouvez toujours vouloir éviter de placer des appels de fonction dans une instruction Assert. Ces appels doivent être sécurisés, car les instructions Trace.Assert ne sont pas éliminées dans une version Release. Cependant, si vous évitez ces constructions en règle générale, vous ferez moins d'erreurs lors de l'utilisation de Debug.Assert.

Exigences relatives à Trace et Debug

Si vous créez votre projet en utilisant les Assistants Visual Studio, le symbole TRACE est défini par défaut dans les configurations Release et Debug. Le symbole DEBUG est défini par défaut uniquement dans la version Debug.

Sinon, pour que les méthodes Trace fonctionnent, votre programme doit avoir l'un des éléments suivants en haut du fichier source :

#Const TRACE = True en Visual Basic
#define TRACE en Visual C# et C++

Ou votre programme doit être généré avec l'option TRACE :

/d:TRACE=True en Visual Basic
/d:TRACE en Visual C# et C++

Si vous avez besoin d'utiliser les méthodes Debug dans une version Release C# ou Visual Basic, vous devez définir le symbole DEBUG dans votre configuration Release.

C++ ne prend pas en charge les méthodes de classe Debug. Vous pouvez accomplir le même effet grâce à la classe Trace avec compilation conditionnelle, telle que #ifdef DEBUG... #endif. Vous pouvez définir ces symboles dans la boîte de dialogue Pages de propriétés de <Projet>. Pour plus d'informations, consultez Modification des paramètres de projet pour une configuration Debug Visual Basic ou Modification des paramètres de projet pour une configuration Debug C ou C++.

Arguments Assert

Trace.Assert et Debug.Assert utilisent trois arguments au maximum. Le premier argument, qui est obligatoire, est la condition que vous souhaitez vérifier. Si vous appelez Trace.Assert(Boolean) ou Debug.Assert(Boolean) avec un seul argument, la méthode Assert vérifie la condition et, si le résultat est false, renvoie le contenu de la pile des appels dans la fenêtre Sortie. L'exemple suivant affiche Trace.Assert(Boolean) et Debug.Assert(Boolean) :

[Visual Basic]

Debug.Assert(stacksize > 0)
Trace.Assert(stacksize > 0)

[C#]

Debug.Assert ( stacksize > 0 );
Trace.Assert ( stacksize > 0 );

Le deuxième et le troisième arguments, s'ils sont présents, doivent être des chaînes. Si vous appelez Trace.Assert ou Debug.Assert avec deux ou trois arguments, le premier argument est une condition. La méthode vérifie la condition et, si le résultat est false, renvoie les deuxième et troisième chaînes. L'exemple suivant montre Debug.Assert(Boolean, String) et Trace.Assert(Boolean, String) utilisés avec deux arguments.

[Visual Basic]

Debug.Assert(stacksize > 0, "Out of stack space")
Trace.Assert(stacksize > 0, "Out of stack space")

[C#]

Debug.Assert ( stacksize > 0, "Out of stack space" );
Trace.Assert ( stacksize > 0, "Out of stack space" );

L'exemple suivant affiche Assert et Assert :

[Visual Basic]

Debug.Assert(stacksize > 0, "Out of stack space. Bytes left:" , Format(size, "G"))
Trace.Assert(stacksize > 0, "Out of stack space. Bytes left:" , Format(size, "G"))
Trace.Assert(stacksize > 0, "Out of stack space. Bytes left:", "inctemp failed on third call" )

[C#]

Debug.Assert ( stacksize > 100, "Out of stack space" , "Failed in inctemp" );
Trace.Assert ( stacksize > 0, "Out of stack space", "Failed in inctemp" );

Personnalisation du comportement de Assert

Si vous exécutez votre application en mode interface utilisateur, la méthode Assert affiche la boîte de dialogue Échec de l'assertion lorsque la condition échoue. Les actions qui se produisent lors de l'échec d'une assertion sont contrôlées par la propriété Listeners ou la propriété Listeners.

Vous pouvez personnaliser le comportement en sortie en ajoutant un objet TraceListener à la collection Listeners, en supprimant un TraceListener de la collection Listeners ou en substituant la méthode TraceListener.Fail par un TraceListener existant pour modifier son comportement.

Par exemple, vous pouvez substituer la méthode TraceListener.Fail pour écrire dans un journal des événements au lieu d'afficher la boîte de dialogue Échec de l'assertion.

Pour personnaliser la sortie de cette façon, votre programme doit contenir un écouteur et vous devez hériter de TraceListener et substituer sa méthode TraceListener.Fail.

Pour plus d'informations, consultez Écouteurs de la trace.

Définition d'assertions dans les fichiers de configuration

Vous pouvez définir des assertions dans le fichier de configuration de votre programme ainsi que dans votre code. Pour plus d'informations, consultez Trace.Assert ou Debug.Assert.

Voir aussi

Partager via

Assertions dans du code managé

Debug.Assert, méthode

Effets secondaires de Debug.Assert

Exigences relatives à Trace et Debug

Arguments Assert

Personnalisation du comportement de Assert

Définition d'assertions dans les fichiers de configuration

Voir aussi

Tâches

Concepts

Référence

Autres ressources

Ressources supplémentaires