Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Déboguer simplement : les points d'arrêt par code

Voici une astuce toute simple comme je les aime mais qui rend bien des services !

Lorsqu'on débogue une application on utilise fréquemment les points d'arrêt notamment lorsqu'on soupçonne un problème dans une partie de code précise. Tous les développeurs connaissent les points d'arrêt et savent s'en servir. Il est déjà plus rare de voir un développeur se servir des points d'arrêt conditionnels, pourtant un simple clic-droit sur le rond rouge dans la marge (symbolisant le point d'arrêt) permet de fixer une condition liée au code ou au nombre de passages par exemple. Il existe d'autres possibilités d'une grande richesse et si vous ne les connaissez pas, au moins une fois pour voir, faites un clic droit sur un point d'arrêt et jouez un peu avec les options, vous comprendrez alors comment vous auriez pu gagner des minutes ou des heures précieuses si vous aviez connu cette astuce plus tôt !

Mais ce n'est pas des points d'arrêt conditionnels que je voulais vous parler aujourd'hui mais d'une autre astuce encore moins connue / utilisée : les points d'arrêt par code.

En effet, le debugger de Visual Studio peut, en partie, être contrôlé par le code lui-même en utilisant la classe Debugger de l'espace de noms System.Diagnostics.

Les méthodes statiques de cette classe permettent par exemple de savoir si le debugger est lancé ou non, voire de lancer s'il n'est pas actif. La méthode Break() quant à elle permet simplement de faire un point d'arrêt et c'est elle qui nous intéresse ici.

Plutôt que d'attendre qu'une exception soit levée, de revenir dans le code, de placer un point d'arrêt et de relancer l'application en espérant que "ça plante" de la même façon, il est plus facile de prévoir d'emblée le point d'arrêt là où il existe un risque d'y avoir un problème, notamment en phase de mise au point d'un code. Un simple Debugger.Break(), dès qu'il sera rencontré lors de l'exécution, aura le même effet qu'un point d'arrêt inconditionnel placé dans Visual Studio. Bien entendu, le break peut être programmer selon un test (valeur non valide d'une propriété par exemple). Dans un tel cas dès que l'application rencontrera le break elle déclenchera le passage en mode debug sur le "point d'arrêt" ainsi défini. Le développeur peut se dégager l'esprit pour d'autres tâches de test, dès que le break sera rencontré VS passera en debug immédiatement sans risque de "louper" le problème ou de le voir trop tard et de ne plus avoir accès à certaines variables.

un petit exemple :

class Program
{
   static void Main(string[] args)
   { 
       var list = new List<Book>
       {   new Book {Title = "Livre 1", Year = 1981},
           new Book {Title = "Livre 2", Year = 2007},
           new Book {Title = "Livre 3", Year = 2040} };

foreach (var book in list) { Console.WriteLine(book.Title+" "+book.Year); }
}

class Book
{
   private int year;

   public string Title { get; set; }
   public int Year
  { get { return year; }
     set {
              if (value > 1980 && value < DateTime.Now.Year) year = value;
              else Debugger.Break();
                   // throw new Exception("L'année " + value + " n'est pas autorisée");
           }
   }
}

Lors de l'initialisation de la collection "list" dans le Main(), l'année du troisième livre (2040) déclenchera le break. On pourra alors directement inspecter le code et savoir pourquoi ce "logiciel" plante dès son lancement...  On voit qu'ici j'ai mis en commentaire l'exception qui sera lancée par la version "finale" du code. A sa place j'ai introduit l'appel à Break(). Rien à surveiller. Si le problème vient de là (ce qui est le cas ici) VS passera tout seul en debug...

C'est pas chouette ça ?

Alors Stay Tuned !

 

 

 

blog comments powered by Disqus