Moc breakpointów w VS

2008-11-21 20:28

Śledzenie wykonywania programu to świetna metoda na znajdowanie przyczyn wielu błędów. Ale żeby coś sensownie śledzić, to najpierw zwykle trzeba dojść do interesującego fragmentu kodu – to zaś umożliwiają punkty przerwania, czyli po polsku breakpointy ;)
W najbardziej podstawowej wersji działają one niezwykle prosto i zwyczajnie zatrzymują debuger na wskazanej instrukcji. W Visual Studio możemy jednak wykorzystać w sposób znacznie bardziej zaawansowany; wystarczy bowiem – po postawieniu breakpointa kliknąć weń prawym przyciskiem myszy i już ukazuje się nam wielce interesujące menu podręczne. Mamy tam kilka przydatnych opcji, do których należą między innymi:

  • Location – umożliwia precyzyjne określenie, na jakiej instrukcji stawiamy breakpoint. Jest to użyteczne, gdy mamy np. krótką jednolinijkową instrukcję if, a punkt przerwania chcemy ustawić nie na sprawdzaniu jej warunku, lecz w środku jej bloku.
  • Hit Count – wyświetla nam okienko, w którym widać, ile razy breakpoint został “trafiony” od początku sesji debuggera. Możemy też określić tam, aby zatrzymanie następowało tylko przy jakimś określonym przejściu przez breakpoint. Może to być przydatne, jeśli np. debugujemy pętle, o której wiemy, że zaczyna się psuć w okolicach 4867 iteracji – właśnie tyle wciśnięć F5 możemy w ten sposób oszczędzić :)
  • When Hit – ta opcja pozwala z kolei na wykonanie dodatkowych akcji w momencie trafienia breakpointa, co obejmuje nawet możliwość uruchomienia makra sterującego zachowaniem IDE (!). Prawdopodobnie bardziej przydatne jest jednak wypisywanie komunikatu w oknie Output debugera; opcja ta jest na tyle zaawansowana, że może właściwie eliminować użycie funkcji typu OutputDebugString czy nawet dedykowanych logerów.
  • Condition to z kolei bodaj najprzydatniejsza opcja ze wszystkich. Pozwala mianowicie na określenie dodatkowego warunku, który musi być spełniony, aby punkt przerwania zadziałał. Jest to nieocenione do znajdowania błędów w skomplikowanych pętlach warunkowych, że o funkcjach rekurencyjnych nie wspomnę.
  • Filter to z kolei zaawansowana opcja, umożliwiająca ograniczenie działania breakpointa tylko do wybranych procesów lub wątków (rozpoznawanych przez identyfikator lub nazwę). Jak nietrudno się domyślić, przydaje się w programach równoległych.
  • W końcu Disable Breakpoint pozwala czasowo wyłączyć breakpoint bez usuwania go, czyli utraty tych wszystkich ustawień, które pieczołowicie wpisywaliśmy przy pomocy powyższych opcji :)

I tyle właśnie potrafią breakpointy w VS. Całkiem sporo, jak na jedną niepozorną, czerwoną kropkę :]

Tags: ,
Author: Xion, posted under Applications, Programming »


4 comments for post “Moc breakpointów w VS”.
  1. SirMike:
    November 21st, 2008 o 21:57

    Szkoda, ze nie potrafia tego w wersji Express :D
    Bynajmniej dla C# to srodowisko jest tak biedne, ze szkoda gadac.

  2. vashpan:
    November 22nd, 2008 o 10:06

    Ha, to samo mialem napisac ;) Na cale szczescie mam studenckiego VS 2008 Pro, ale kiedy ostatnio bawilem sie XNA 2.0, ktory wymagal wersji 2005, pracowalem pod 2005 Express, i bardzo sie zdziwilem ze breakpointy sa wlasnie az tak okrojone.

  3. SirMike:
    November 22nd, 2008 o 15:06

    Im dluzej pracuje z wersja Express tym wieksze mam wrazenie, ze to badziew okropny:

    – breakpointy okrojone (listy tez nie ma)
    – debuggera nie podepniesz pod proces
    – przy starcie aplikacji nie uruchomisz customowego procesu

    Dobrze, ze jest WinDbg.

  4. Reg:
    November 23rd, 2008 o 12:45

    Szkoda tylko, że w Condition nie można porównywać stringów.

Comments are disabled.
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.