Partager via

Assertions dans du code managé

  • Article

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

La Méthode Debug.Assert

Effets secondaires de Debug.Assert

Exigences relatives à Trace et Debug

Arguments Assert

Personnalisation du comportement d’Assert

Définition d’assertions dans les fichiers de configuration

Assertions dans l'espace de noms System.Diagnostics

En Visual Basic et Visual C#, vous pouvez utiliser la méthode Assert de Debug ou Trace, qui est dans l'espace de noms System.Diagnostics. Les méthodes de la classe Debug ne sont pas incluses dans une version Release de votre programme ; par conséquent, elles n’augmentent pas la taille ou ne réduisent pas la vitesse de votre code de version release.

C++ ne prend pas en charge les méthodes de classe Debug. Vous pouvez obtenir le même effet en utilisant la classe Trace avec la compilation conditionnelle, telle que #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, 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 :

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 :

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

Avant de retirer de l'argent du compte, il est préférable de s’assurer que le solde de votre compte est suffisant pour couvrir la somme que vous allez retirer. Vous pouvez écrire une assertion pour contrôler le solde :

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

Notez que les appels à la méthode System.Diagnostics.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 System.Diagnostics.Debug.Assert par System.Diagnostics.Trace.Assert, qui ne disparaît pas dans la version Release :

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

Dans cette rubrique

Effets secondaires de Debug.Assert

Lorsque vous utilisez System.Diagnostics.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 :

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

Cette utilisation de System.Diagnostics.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 System.Diagnostics.Debug.Assert. Utilisez une variable temporaire à la place :

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 dans une instruction Assert. Ces appels doivent être sécurisés, car les instructions System.Diagnostics.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 System.Diagnostics.Debug.Assert.

Dans cette rubrique

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 obtenir le même effet en utilisant la classe Trace avec la compilation conditionnelle, telle que #ifdef DEBUG... #endif. Vous pouvez définir ces symboles dans la boîte de dialogue <Projet> Pages 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

System.Diagnostics.Trace.Assert et System.Diagnostics.Debug.Assert utilisent trois arguments au maximum. Le premier argument, qui est 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 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 System.Diagnostics.Trace.Assert(Boolean) et System.Diagnostics.Debug.Assert(Boolean) :

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 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, renvoie les deuxième et troisième chaînes. L’exemple suivant montre System.Diagnostics.Debug.Assert(Boolean, String) et System.Diagnostics.Trace.Assert(Boolean, String) utilisés 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és 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 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 quand 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 System.Diagnostics.TraceListener.Fail par un TraceListener existant pour modifier son comportement.

Par exemple, vous pouvez substituer la méthode System.Diagnostics.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 System.Diagnostics.TraceListener.Fail.

Pour plus d’informations, consultez Écouteurs de suivi.

Dans cette rubrique

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 System.Diagnostics.Trace.Assert ou System.Diagnostics.Debug.Assert.

Contenu connexe