Der Debugger von Visual Studio ist ein mächtiges und nützliches Werkzeug, um die Ursachen für fehlerhaftes Anwendungsverhalten schnell ermitteln zu können. Eines der praktischsten Funktionen ist wohl die Möglichkeit, bei Ausnahmen die Ausführung anzuhalten. Visual Studio zeigt Details zur Exception und markiert die Codezeile, in der sie aufgetreten ist. Außerdem lassen sich die aktuellen Inhalte aller Variablen anzeigen, wodurch sich die Fehlerquelle häufig zumindest eingrenzen lässt.
Es gibt allerdings bestimmte Fälle, in denen Visual Studio dies nicht tut. Beispielsweise bei behandelten Ausnahmen, die mit einem Try-Catch-Block abgefangen werden. Insbesondere in externen Librarys kann dies die Fehlersuche deutlich erschweren. Beispielsweise wenn sämtliche Exception angefangen und nur über ein Error-Event übermittelt werden. Demonstrieren lässt sich dies mit wenigen Zeilen beispielsweise durch provozieren einer NullReference-Exception:
In diesem Falle können wir standardmäßig nicht mit dem Debugger arbeiten. Uns steht nur die Ausnahme und die Zeilennummer der Stacktrace zur Verfügung.
Bestimmen, bei welchen Ausnahmen Visual Studio unterbricht
Um dies zu ändern, müssen wir Visual Studio zwingen, bei bestimmten Ausnahmetypen immer Anzuhalten und den Debugger zu starten. Dies lässt sich über die Ausnahmeeinstellungen festlegen. Sie können über Debuggen > Fenster > Ausnahmeeinstellungen oder alternativ die Tastenkombination Strg + Alt + E geöffnet werden. In der sich öffnenden Liste dürften vor allem die Common Language Runtime Exceptions interessant sein. Sie enthalten sämtliche .NET Ausnahmen. Man kann hier direkt einen Haken setzen oder die Liste öffnen, und nur spezifische Ausnahmen aktivieren.
In unserem Beispiel wollen wir den Debugger nur bei NullReferenceExceptions starten. Am schnellsten finden wir diese über das Suchfeld rechts oben:
Beim gleichen Code wird Visual Studio nun anhalten und bietet wie bei unbehandelten Ausnahmen die Möglichkeit zu debuggen:
Ohne das explizite aktivieren wird Visual Studio natürlich nicht bei behandelten Ausnahmen anhalten. In diesem Fall geht die IDE richtigerweise davon aus, dass der Entwickler den Fehler angemessen behandelt, damit das Programm weiter laufen kann. Oder die Ausführung bei entsprechend schweren Fehlern unterbricht. Dieses Verhalten zu ändern macht nur zu Fehlersuche im Rahmen von Entwicklungszwecken sinn.
Nur eigener Code oder auch externe Exceptions?
Standardmäßig funktioniert dies nur mit dem eigenen Code. Nicht berücksichtigt werden Exceptions, die in externen Komponenten geworfen werden wie beispielsweise Frameworks oder sonstige eingebundene Librarys. Ein Beispiel ist die serverseitige Komponente von SignalR: Sie fängt alle Exceptions ab und feuert ein Error-Event. Mit den Standardeinstellungen würde Visual Studio bei einer solchen Ausnahme entgegen dem obigen Beispiel nicht anhalten.
Je nach Anwendungsfall ist diese Verhalten erwünscht oder eben nicht. Es lässt sich in den Debug-Optionen im Menü Debug > Optionen unter dem Punkt Allgemein anpassen. Ab Werk ist die Einstellung Nur meinen Code aktivieren eingeschaltet. Sie verursacht das eben erklärte Verhalten. Möchte man dagegen Visual Studio auch bei Anwendungen in externen Komponenten anhalten lassen, muss dieser Haken entfernt werden.
Zu beachten ist, dass Visual Studio die entsprechenden Symbole (*.pdb Datei) der externen Library benötigt. Die Program DataBase Datei enthält Informationen, die Visual Studio für das Debuggung benötigt. Für das .NET Framework und alle dazugehörigen Komponenten bietet Microsoft einen Symbolserver an, von dem sie bei Bedarf automatisch geladen werden:
Dies muss aber nicht auch zwingend bei Fremd-Entwicklungen der Fall sein. Dort können die Entwickler ihre Software ohne Symbole ausliefern. Liegt auch kein Quellcode vor um diese selbst zu generieren, ist das Debuggen mit Visual Studio ohne weiteres nicht möglich.