Dziś kolejne, mam nadzieję, ciekawe zastosowanie warunkowego breakpointu. Zanim jednak przejdziemy do omawiania nakreślmy naszą sytuację wyjściową.
Załóżmy, że mamy kawałek kodu aplikacji, który jest dość często wykorzystywany z różnych miejsc.
To co on robi nie jest ważne. Istotne jest, że chcielibyśmy postawić w niej breakpoint’a i zobaczyć jak się zachowuje w pewnych sytuacjach. Oczywiście chcielibyśmy, aby breakpoint nie zatrzymywał się w niej zawsze a tylko w wybranych sytuacjach. Moglibyśmy założyć warunkową pułapkę uwzględniając dane, które są w coefficients. Co jeśli one są zmienne? Wiemy jednak że wywołania, którym chcielibyśmy się przyjrzeć dokładniej pochodzą z kilku funkcji, a co więcej wiemy, że na pewno nie pochodzą z CalculateCoeffs. Spróbujmy wykorzystać warunkowy breakpoint wraz z klasami StackTrace i/lub StackFrame.
Czym jest i do czego służy StackTrace, mam nadzieję nikomu nie trzeba tłumaczyć natomiast zobaczymy co nam daje ta klasa w .NET. Pozwalają one uzyskanie ścieżki wywołań metod naszego kodu. Połączmy zatem warunkowy breakpoint ze StackTrace. Co nam wyjdzie?
Przeanalizujmy co mamy. Tworzymy sobie ramkę stosu wywołań (można tu posłużyć się także klasą StackTrace i metodą GetFrame). Do konstruktora przekazujemy parametr 1 co oznacza, że chcemy ominąć aktualną ramkę (czyli metodę w której jesteśmy) a pobrać dane metody ją wywołującej – czyli rodzica. Dalej to już z górki. Pobieramy metodę (GetMethod) oraz jej nazwę (Name) i sprawdzamy czy nie zawiera nazwy metody, która nas nie interesuje. Voila, gotowe.
Jako “zadanie domowe” można pokusić się o napisanie warunku, który spowoduje zatrzymanie jeśli stack trace nie zawiera wywołania z jakiegoś konkretnego modułu.
Miłego debuggowania.
Founder of Octal Solutions a .NET software house.
Passionate dev, blogger, occasionally speaker, one of the leaders of Wroc.NET user group. Microsoft MVP. Podcaster – Ostrapila.pl