myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Knowledge Base » Artikel » [Artikel] Debugger: Wie verwende ich den von Visual Studio?
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

[Artikel] Debugger: Wie verwende ich den von Visual Studio?

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
MrSparkle MrSparkle ist männlich
myCSharp.de-Team

avatar-2159.gif


Dabei seit: 16.05.2006
Beiträge: 5.185
Herkunft: Leipzig


MrSparkle ist offline

[Artikel] Debugger: Wie verwende ich den von Visual Studio?

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Wie verwende ich den Debugger von Visual Studio?

Bugs sind kleine, gemeine  Schädlinge, die sich in unserem Programmcode breitmachen, und ihn daran hindern, korrekt zu funktionieren. Aber wie spürt man einen Bug zwischen tausenden von Programmzeilen auf? Seit dem ersten Bug von 1947 haben findige Menschen dazu beigetragen, dass uns diese Arbeit heute zum großen Teil von einem Programm abgenommen wird: dem Debugger. Und das Beste daran ist, dass er uns sogar in der kostenlosen Express-Version von Visual Studio zur Verfügung steht.

Aber wie verwendet man den Debugger, um einen Fehler aufzuspüren?

In den meisten Fällen macht sich ein Programmfehler dadurch bemerkbar, dass das Programm nicht tut, was es tun soll oder dadurch, dass eine Ausnahme (Exception) ausgelöst wird. In letzterem Fall hat man zwar die Stelle lokalisiert, an der der Fehler seine Auswirkung gezeigt hat, aber noch nicht dessen Ursache. Um an die Fehlerursache zu kommen, müsste man wissen, welche Werte bestimmte Variablen haben. Und es wäre hilfreich, das Programm Schritt für Schritt bzw. Zeile für Zeile auszuführen und zu beobachten, wie sich diese Werte ändern. Damit haben wir bereits die wesentlichen Funktionen des Debuggers in Visual Studio vorweggenommen:


Ein Breakpoint in VisualStudio
Ein Breakpoint in VisualStudio
Haltepunkte (Breakpoints)
Damit man ein Programm Schritt für Schritt durchlaufen kann, muss man es zunächst anhalten bzw. pausieren. Mit einem Rechtsklick auf das Projekt -> Debuggen -> In Neue Instanz springen (Debug -> Step Into new instance) wird das Programm gestartet und an der ersten Anweisung angehalten. Meistens genügt das allerdings nicht, und man möchte direkt in eine bestimmte Methode oder eine bestimmte Schleife springen.

Das Programm wurde an einem Breakpoint angehalten
Das Programm wurde an einem Breakpoint angehalten
Um das Programm an einer beliebigen Stelle im Code anzuhalten, setzt man einen Haltepunkt. Dazu klickt man links neben die entsprechende Programmzeile oder drückt F9. Die Zeile wird dann rot eingefärbt und es erscheint ein roter Punkt (der Halte-"Punkt"). Das Programm wird jetzt immer dann pausiert, wenn diese Codestelle bei der Ausführung erreicht wird.


Die Breakpoint-Bedingung
Die Breakpoint-Bedingung
Bedingte Haltepunkte (Conditional Breakpoints)
In manchen Situationen hat man bereits festgestellt, dass ein Fehler immer nur unter bestimmten Umständen auftritt, z.B. wenn eine Variable i den Wert 0 hat. Damit das Programm auch nur dann angehalten wird, kann man mit der rechten Maustaste auf einen Haltepunkt klicken und im Kontextmenü den Befehl für die Bedingung auswählen. Dort kann man dann z.B. i == 0 eingeben oder (fast) beliebige andere Bedingungen.


Variablenwerte überwachen mit
Variablenwerte überwachen mit "DataTips"
Variablen-Überwachung (Watches)
Während das Programm angehalten ist - beispielsweise durch einen Haltepunkt oder eine Ausnahme (Exception) - kann man einfach mit der Maus über eine Variable fahren. Dann erscheint eine "DataTip" genannte Kurzinfo mit dem Typ und dem Wert der Variablen. Die meisten Fehler lassen sich bereits dadurch aufspüren, da man sehr schnell erkennt, wenn eine Variable einen unerwarteten Wert hat, wie z.B. null. Man kann die Werte übrigens dort auch direkt verändern, indem man doppelt auf den angezeigten Wert klickt.

Die "DataTips" haben einen kleinen Pin, der verhindert, dass sie automatisch wieder geschlossen werden. So kann man sich mehrere Variablen zur gleichen Zeit anschauen.

Das Variablen-Überwachungsfenster
Das Variablen-Überwachungsfenster
Um dabei nicht die Übersicht zu verlieren, gibt es das Überwachungs-Fenster, in dem man beliebige Anweisungen (nicht nur Variablen) eintragen, überwachen und verändern kann. Alternativ dazu kann man im Quellcode eine Anweisung markieren und über "Überwachung hinzufügen" ("Add Watch") im Kontextmenü zum Überwachungsfenster hinzufügen.


Einzelschritt-Debugging (Single Step Debugging)
Hat man sich mit den bisher genannten Möglichkeiten einen Überblick über den aktuellen Zustand des Programms geschaffen, will man oft wissen, welcher Code weiterhin ausgeführt wird, und wie sich dadurch die Werte der Variablen ändern. So kann man genau die Codezeile aufspüren, in der die Fehlerursache liegt (und sie beheben).

Das geht mit der Einzelschritt-Funktion (F11). Dann wird die Programmausführung nach jeder Anweisung wieder unterbrochen und man kann Schritt für Schritt durch das Programm gehen, um den Programmablauf genauestens nachzuvollziehen. Mit F10 kann man Methoden-Aufrufe überspringen, um zu verhindern, dass jede einzelne Anweisung innerhalb einer aufgerufenen Methode ausgeführt wird.

Noch schneller ist es manchmal, einige zusätzliche Haltepunkte an den interessanten Codestellen zu setzen und dann das Programm mit F5 weiter auszuführen. Das Programm wird dann beim ersten Haltepunkt, der erreicht wird, wieder angehalten. So lässt sich gezielt herausfinden, welche Codeblöcke bei der Ausführung durchlaufen werden und in welcher Reihenfolge sie dabei aufgerufen werden.

Die genannten Möglichkeiten des Einzelschritt-Debuggings helfen somit einerseits bei der Überwachung des Programmzustands (z.B. fehlerhafte Werte in Variablen) als auch beim Aufspüren von Fehlern im Programmablauf (z.B. bei fehlerhaften Abbruchbedingungen in Schleifen).


Nächste Anweisung setzen im Kontextmenü
Nächste Anweisung setzen im Kontextmenü
Nächste Anweisung setzen (Set Next Statement)
Um selbst in den Programmablauf einzugreifen, z.B. um eine Funktion ein weiteres Mal aufzurufen oder einen bestimmten Code-Block zu umgehen, gibt es im Kontextmenü die Funktion "Nächste Anweisung festlegen" ("Set Next Statement"). Alternativ kann man den kleinen gelben Pfeil links neben der aktuellen Anweisung auch mit der Maus auf eine andere Position ziehen. Führt man das Programm dann mit F5, F10 oder F11 weiter aus, wird das Programm an dieser Stelle fortgesetzt.


Fehlerbehebung
In Visual Studio gibt es eine sehr hilfreiche Funktion namens  Bearbeiten und Fortfahren / ( Edit and Continue), mit der man während des Debuggens den Code ändern und dann weiter ausführen kann. So kann man Fehler beheben und auch gleich ausprobieren, ob es tatsächlich so funktioniert. Natürlich muss man dafür sorgen, dass die geänderte Zeile erneut ausgeführt wird, z.B. so wie im vorangegangenen Abschnitt beschrieben. Bearbeiten und Fortfahren steht bis einschließlich VisualStudio 2012 allerdings nur für x86-Anwendungen zur Verfügung.


Systematische Fehlersuche
Um die Qualität einer Anwendung sicherzustellen und Fehler systematisch aufzuspüren, sollte man unbedingt jede Funktion mithilfe von  Unit-Tests überprüfen, siehe auch  [Artikel] Unit-Tests: Einführung in das Unit-Testing mit VisualStudio.

Und noch ein Tipp: Auch bei hartnäckigen Fehlern sollte man nicht die Geduld verlieren sondern systematisch vorgehen. Eine Anleitung, wie man in solchen Fällen vorgehen kann, gibt es unter  [Tutorial] Vertrackte Fehler durch Vergleich von echtem Projekt mit minimalem Testprojekt finden.


Systematische Fehlervermeidung
Um die gewünschte Funktionalität eines Programms von vornherein und dauerhaft zu gewährleisten, gibt es nur eine Lösung, nämlich konsequentes  Test-Driven Development (TDD).


Fazit
Mithilfe von Funktionen wie Einzelschritt-Debugging, Haltepunkten und Variablen-Überwachung lassen sich Fehler in Programmen schnell und zielsicher aufspüren und beheben.
02.09.2013 21:05 Beiträge des Benutzers | zu Buddylist hinzufügen
MatthiasDietschweiler
myCSharp.de-Mitglied

Dabei seit: 29.06.2012
Beiträge: 7


MatthiasDietschweiler ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Verständlich geschrieben. Und sicher hilfreich für jeden Ein- / Umsteiger. Daumen hoch
Nebensätzlich erwähnenswert wäre sicher noch das "Attach Process", da früher oder später jeder vor der Aufgabe steht z.B. einen Service zu debuggen.
Eine schöne Abrundung für die Erklärung von Breakpoints wäre noch das De- Aktivieren. Was m.E. sehr hilfreich ist für das Szenario in dem man zuerst mehrere BPs setzt um einen grösseren Ablauf anzuschauen und dann nach und nach vertieft weitere BPs hinzufügt.
03.09.2013 06:37 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
EifelYeti EifelYeti ist männlich
myCSharp.de-Mitglied

avatar-3408.jpeg


Dabei seit: 10.07.2012
Beiträge: 64
Entwicklungsumgebung: VS 2010/2013
Herkunft: Eifel


EifelYeti ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Für die jenigen die nur in der Expressversion von Visual Studio [2010 oder tiefer] arbeiten, gibt es die Möglichkeit der bedingten Haltepunkte (Conditional Breakpoints) nicht von Haus aus.

Allerdings kann man sich mit:

C#-Code:
#if DEBUG
    if( i == 0 )  System.Diagnostics.Debugger.Break();
#endif

seinen eigenen Conditional Breakpoint bauen.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von EifelYeti am 03.09.2013 13:28.

03.09.2013 07:58 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
pinki
myCSharp.de-Mitglied

avatar-4072.jpg


Dabei seit: 24.08.2008
Beiträge: 664
Herkunft: OWL


pinki ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von EifelYeti:
Für die jenigen die nur in der Expressversion von Visual Studio arbeiten, gibt es die Möglichkeit der bedingten Haltepunkte (Conditional Breakpoints) nicht von Haus aus.

Seit Visual Studio Express 2012 scheint das auch da möglich zu sein. :)
03.09.2013 13:18 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
EifelYeti EifelYeti ist männlich
myCSharp.de-Mitglied

avatar-3408.jpeg


Dabei seit: 10.07.2012
Beiträge: 64
Entwicklungsumgebung: VS 2010/2013
Herkunft: Eifel


EifelYeti ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Huch das habe ich nicht geprüft, Danke! :) Hatte nur gemerkt das es in 2010 nicht klappt.
Ich habe meinen Beitrag entsprechend geändert.
03.09.2013 13:29 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Zwischen diesen beiden Beiträgen liegt mehr als ein Jahr.
Ezio Ezio ist männlich
myCSharp.de-Mitglied

avatar-3575.png


Dabei seit: 28.08.2014
Beiträge: 189
Entwicklungsumgebung: VS 2013


Ezio ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Aufgrund der häufigen Verweise auf diesen Artikel möchte ich noch anmerken, dass das  openbook: Visual C# vom Rheinwerk-Verlag dieses Thema auch behandelt.
 Kapitel 7: Fehlerbehandlung und Debugging beinhaltet  Kapitel 7.3: Fehlersuche mit Visual Studio [...].
Vielleicht hilft dem einen oder anderen die andere Art der Formulierung weiter.

VG Ezio
02.07.2015 15:15 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 6 Jahre.
Der letzte Beitrag ist älter als 4 Jahre.
Antwort erstellen


© Copyright 2003-2019 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 19.09.2019 17:01