Partager via


Assertions dans le code managé

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. Si vous exécutez avec une version debug, votre programme passe en mode arrêt.

Dans cette rubrique

Assertions dans l’espace de noms System.Diagnostics

Méthode Debug.Assert

Effets secondaires de Debug.Assert

Exigences pour le suivi et le débogage

Valider les arguments

Personnalisation du comportement Assert

Définition d’assertions dans les fichiers de configuration

Assertions dans le namespace System.Diagnostics

Dans Visual Basic et Visual C#, vous pouvez utiliser la méthode Assert soit à partir de Debug, soit à partir de Trace, qui se trouvent dans le namespace System.Diagnostics. Debug Les méthodes de classe ne sont pas incluses dans une version Release de votre programme. Elles n’augmentent donc pas la taille ou réduisent la vitesse de votre code de mise en production.

C++ ne prend pas en charge les méthodes de Debug classe. Vous pouvez obtenir le même effet en utilisant la classe Trace avec la compilation conditionnelle, comme #ifdef DEBUG... #endif.

Dans cette rubrique

Méthode Debug.Assert

Utilisez librement la méthode System.Diagnostics.Debug.Assert pour tester les conditions qui doivent avoir la valeur true si votre code est correct. Par exemple, supposons que vous ayez é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 à l’aide d’une assertion :

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 effectuée, de sorte qu’il n’y a pas de surcharge supplémentaire.

Voici un autre exemple. Vous disposez d’une classe qui implémente un compte de vérification, comme suit :

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

Avant de retirer de l’argent du compte, vous souhaitez vous assurer que le solde du compte est suffisant pour couvrir le montant que vous préparez à retirer. Vous pouvez écrire une assertion pour vérifier le solde :

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

Notez que les appels à la System.Diagnostics.Debug.Assert méthode disparaissent lorsque vous créez une version Release de votre code. Cela signifie que l’appel qui contrôle l’équilibre disparaît dans la version release. Pour résoudre ce problème, vous devez remplacer System.Diagnostics.Debug.Assert par System.Diagnostics.Trace.Assert, qui ne disparaît pas dans la version Release :

Les appels à System.Diagnostics.Trace.Assert ajoutent une surcharge à votre version de publication, contrairement aux appels à System.Diagnostics.Debug.Assert.

Dans cette rubrique

Effets secondaires de Debug.Assert

Lorsque vous utilisez System.Diagnostics.Debug.Assert, assurez-vous que tout code à l’intérieur Assert ne modifie pas les résultats du programme s’il Assert est supprimé. Sinon, vous pouvez introduire accidentellement un bogue qui s’affiche uniquement dans la version Release de votre programme. Soyez particulièrement prudent sur les assertions qui contiennent des appels de fonction ou de procédure, comme l’exemple suivant :

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

Cette utilisation System.Diagnostics.Debug.Assert peut sembler sûre à première vue, mais supposons que la fonction meas met à jour un compteur chaque fois qu’il est appelé. Lorsque vous générez la version Release, cet appel à meas est éliminé. Par conséquent, le compteur n’est pas mis à jour. Il s’agit d’un exemple de fonction avec un effet secondaire. L’élimination d’un appel à une fonction ayant des effets secondaires peut entraîner un bogue qui apparaît uniquement dans la version release. Pour éviter de tels problèmes, ne placez pas d’appels de fonction dans une System.Diagnostics.Debug.Assert instruction. Utilisez plutôt une variable temporaire :

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

Même lorsque vous utilisez System.Diagnostics.Trace.Assert, vous pouvez toujours vouloir éviter de placer des appels de fonction à l’intérieur d’une Assert instruction. Ces appels doivent être sécurisés, car System.Diagnostics.Trace.Assert les instructions ne sont pas éliminées dans une build Release. Toutefois, si vous évitez de telles constructions comme une question d’habitude, vous êtes moins susceptible de faire une erreur lorsque vous utilisez System.Diagnostics.Debug.Assert.

Dans cette rubrique

Exigences de traçage et de débogage

Si vous créez votre projet à l’aide des 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 build Debug.

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

Assurer les arguments

System.Diagnostics.Trace.Assert et System.Diagnostics.Debug.Assert prendre jusqu’à trois arguments. Le premier argument, obligatoire, est la condition que vous souhaitez vérifier. Si vous appelez System.Diagnostics.Trace.Assert(Boolean) ou System.Diagnostics.Debug.Assert(Boolean) avec un seul argument, la Assert méthode vérifie la condition et, si le résultat est false, génère le contenu de la pile des appels dans la fenêtre Sortie . L’exemple suivant montre System.Diagnostics.Trace.Assert(Boolean) et System.Diagnostics.Debug.Assert(Boolean):

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

Les deuxième et troisième arguments, s’ils sont présents, doivent être des chaînes. Si vous appelez System.Diagnostics.Trace.Assert ou System.Diagnostics.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, génère la deuxième chaîne et les troisième chaînes. L’exemple suivant montre System.Diagnostics.Debug.Assert(Boolean, String) et System.Diagnostics.Trace.Assert(Boolean, String) utilisé avec deux arguments :

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

L’exemple suivant montre System.Diagnostics.Debug.Assert(Boolean, String, String) et System.Diagnostics.Trace.Assert(Boolean, String, String) utilisé avec trois arguments :

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

Dans cette rubrique

Personnalisation du comportement Assert

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

Vous pouvez personnaliser le comportement de sortie en ajoutant un TraceListener objet à la Listeners collection, en supprimant une TraceListener collection Listeners ou en remplaçant la System.Diagnostics.TraceListener.Fail méthode d’un existant TraceListener pour qu’elle se comporte différemment.

Par exemple, vous pouvez remplacer la System.Diagnostics.TraceListener.Fail méthode pour écrire dans un journal des événements au lieu d’afficher la boîte de dialogue Assertion Failed .

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

Pour plus d’informations, consultez Écouteurs de traçage.

Dans cette rubrique

Définition d’assertions dans les fichiers de configuration

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