conditional_brk
Zapewne wszyscy zdają sobie sprawę, że nasz breakpoint możemy uczynić warunkowym tak aby VS zatrzymało się na nim tylko w specyficznej sytuacji a nie za każdym razem. Gdy breakpoint jest warunkowy jego ikona posiada mały biały plusik tak jak na obrazku w tym paragrafie abyśmy mogli odróżnić go od innych. Dziś pokażemy sobie, że warunkowy breakpoint może być użyty także do innych, mniej oczywistych (mam nadzieję) celów.
Załóżmy, że jesteśmy w trakcie debuggowania dość skomplikowanego kodu (ten poniżej takowym nie jest :)).

while (true)
{
    int receivedBytes = ReceivePackage();
    if (receivedBytes == Package.Length)
    {
        if (ParsePackage())
            break;
    }
}

Przetwarzamy sobie w nim jakieś pakiety. Zrobiliśmy już kawał dobrej roboty w identyfikacji i wiemy, że to ten fragment powoduje błędy. Chcemy zmusić aby flow programu przechodził jednak przez gałąź tak jakby if zwracał true. Oczywiście moglibyśmy zakończyć sesję debuggowania, zmienić kod na if (true) lub całkowicie warunek z if usunąć, tylko w jakim celu? Jeśli dość dużo czasu zajęło nam identyfikowanie problemu, lepiej nie ryzykować konieczności wykonania tej pracy raz jeszcze. Ustawmy na nim warunkowy breakpoint. Klikamy zatem na zwykłym breakpoincie PPM i wybieramy Condition…

condition_brk
Część z osób, które już wcześniej używały dobrodziejstw warunkowych pułapek, może się zdziwić i właśnie krzyczy, że jest błąd: “Tam powinien być znak ==”. Tak, zgoda. W normalnym przypadku tam powinien być znak porównania a nie podstawienia. Ale my nie chcemy normalnego przypadku a ten ciekawy :). Co się stanie w takim przypadku? Tak jak przy zwykłym wykorzystaniu tej funkcji, kod programu będzie wykonywany aż dojdzie do naszej pułapki, zostanie wykonany warunek a ponieważ nie zwróci on prawdy pułapka będzie nieaktywna. Kod wykona się dalej, ale ponieważ w naszym wyrażeniu przypisujemy do zmiennej receivedBytes wartość Package.Length warunek w if będzie prawdziwy i za każdym razem wykona się ParsePackage. Czyż to nie piękne? 🙂 Dla nieznających tej funkcjonalności dodam, że jako warunek można podać w zasadzie dowolne wyrażenie. Chcemy sobie z niego zrobić Tracepoint’a? Nie ma sprawy wystarczy napisać: Console.WriteLine(receivedBytes).I konsola zapełni nam się ładnie danymi… Na plus jest jeszcze to, że działa tam Intellisense, tak więc nie musimy wszystkiego pamiętać.
Mam nadzieję, że pokazałam dość nietypowe zastosowanie warunkowego breakpointa, które może się czasem przydać, aby oszczędzić trochę czasu podczas długich i wycieńczających sesji debuggowania :).