Zum Fußzeileninhalt springen
Iron Academy Logo
C#-Anwendung
C#-Anwendung

Andere Kategorien

C# WinForms Fehlerbehandlung und Debugging — Ein tiefer Einblick mit Tim Corey

Tim Corey
59m 16s

Windows Forms (WinForms) ist eine GUI-Klassenbibliothek zur Erstellung von Windows-Desktopanwendungen, entwickelt und unterstützt von Microsoft. Debugging ist eine der Fähigkeiten, die jeder Entwickler beherrschen muss, aber viele Anfänger fürchten sich davor. In Lektion 20 der Serie "C# App von Anfang bis Ende" nimmt Tim Corey eine fehlerhafte WinForms-Anwendung und erklärt den praktischen Prozess zur Fehlerfindung und -behebung. Diese Lektion behandelt nicht Theorie oder künstliche Beispiele - es geht darum, wie Fehler tatsächlich im produktionsähnlichen Code auftreten und wie ein Entwickler sie ruhig und methodisch angehen sollte.

Um eine Windows Forms-Anwendung zu erstellen, öffnen Sie Visual Studio und wählen Sie die Windows Forms App (.NET Framework) Vorlage für C# aus. Nachdem Sie die C#-Projektvorlage ausgewählt und Ihr Projekt benannt haben, öffnet Visual Studio ein Formular, um die Benutzeroberfläche zu gestalten.

In diesem Artikel werden wir einen genaueren Blick auf die Fehlerbehandlung und das Debugging von C# WinForms werfen, streng nach den Erklärungen und Demonstrationen von Tim Corey aus dem Video. Das Ziel ist zu verstehen, wie Tim debuggt, warum er bestimmte Entscheidungen trifft und welche Einstellung erforderlich ist, um effektiv zu debuggen.

Warum Debugging in Echtwelt-Windows-Forms-Anwendungen wichtig ist

Tim eröffnet die Lektion, indem er erklärt, warum dieses Thema so wichtig ist. Ganz am Anfang sagt er, dass er diese Lektion liebt, weil sie sich mit einer wirklich fehlerhaften Anwendung befasst und nicht mit etwas, das künstlich für den Unterricht erstellt wurde. Laut Tim umfasst die reale Entwicklung immer Fehler, und Entwickler müssen lernen, diese aufzuspüren, anstatt in Panik zu geraten.

Tim erwähnt, dass er oft sieht, wie Studenten ihr gesamtes Projekt löschen, wenn ein Fehler auftritt. Er warnt ausdrücklich vor diesem Ansatz und betont, dass Debugging eine wesentliche professionelle Fähigkeit ist. Statt Probleme hinter den Kulissen zu beheben oder einfach nur zu erklären, was schiefgelaufen ist, entscheidet sich Tim dafür, den gesamten Debugging-Prozess live durchzugehen, damit die Zuschauer sehen können, wie Probleme tatsächlich gelöst werden.

Den Fehler reproduzieren, um ihn zu verstehen

Tim beginnt damit, die Anwendung genau so zu starten, wie es ein Benutzer tun würde. Er erstellt ein Turnier, gibt eine Teilnahmegebühr ein, fügt Teams hinzu und verzichtet absichtlich auf das Erstellen eines Preises. Wenn er auf Turnier erstellen klickt, stürzt die Anwendung ab.

Die angezeigte Fehlermeldung lautet: Eingabestring hatte nicht das richtige Format.

Tim erklärt, dass dies der erste Fehler ist und bevor es weitergeht, muss er verstanden und behoben werden. Er betont, dass das Debuggen damit beginnt, den Fehler konsequent zu reproduzieren und nicht zu raten.

Untersuchung des ersten Fehlers: Ungültige Eingabezeichenfolgen

Tim verfolgt den Fehler zurück zur Umwandlung der Daten in ein MatchupModel. Er bemerkt, dass die Anwendung versucht, eine Gewinner-Team-ID zu konvertieren, obwohl zum Zeitpunkt der Turniererstellung noch kein Gewinner existiert.

Tim erklärt, dass dies dazu führt, dass der Code versucht, einen leeren String zu parsen, was zu der Format-Ausnahme führt. Seine Lösung ist einfach und überlegt:

Er überprüft die Länge des Strings

Wenn es null ist, versucht er nicht, ein Team nachzuschlagen.

  • Stattdessen weist er dem Gewinner einen Nullwert zu

Tim erklärt, dass defensive Überprüfungen wie diese beim Lesen von Eingaben oder Laden von Daten unerlässlich sind. Sobald diese Korrektur vorgenommen ist, setzt er die Ausführung fort, um zu sehen, was das nächste Problem ist.

Ein Stack Overflow Ausnahme tritt auf

Das nächste große Problem tritt als StackOverflowException auf. Tim erklärt, dass dies fast immer bedeutet, dass eine Art von Endlosschleife oder rekursiver Aufruf stattfindet.

Er weist darauf hin, dass die Fehlermeldung selbst darauf hindeutet, aber es wird nicht klar angezeigt, wo die Schleife stattfindet. Tim erklärt, dass Entwickler in diesem Stadium zwei Optionen haben:

  1. Führen Sie die gesamte Anwendung Zeile für Zeile durch

  2. Machen Sie eine fundierte Vermutung, wo das Problem liegen könnte

Wählen Sie den Startpunkt für das Debugging

Tim erklärt, dass es eine gültige Strategie ist, den Code von einem bekannten funktionierenden Punkt aus Schritt für Schritt durchzugehen, wenn Sie nicht wissen, wo Sie anfangen sollen. Er wählt jedoch, Bereiche mit intensiver Schleifenlogik zu überprüfen, insbesondere im Text Connector Prozessor.

Er bemerkt mehrere verschachtelte Schleifen und rekursive Suchvorgänge, die in das Speichern von Runden und Matchups in Dateien verwickelt sind. Basierend auf Erfahrungen vermutet Tim, dass diese Bereiche eher unendliche Schleifen enthalten könnten.

Bevor Tim mit dem Debuggen fortfährt, setzt er die Umgebung zurück, indem er bestehende Dateien löscht. Er erklärt, dass das Debuggen mit halbfertigen oder verbleibenden Dateien zu irreführenden Fehlern und verschwendetem Aufwand führen kann.

Effektiver Einsatz von Haltepunkten und Schrittbefehlen in Visual Studio

Tim setzt Breakpoints an Stellen, an denen die Anwendung noch funktioniert, und beginnt, den Code mit "Step Into" (F11) und "Step Over" durchzugehen.

Er inspiziert sorgfältig:

  • Welche Daten werden geladen

  • Ob Listen leer oder gefüllt sind

  • Wie IDs zugewiesen werden

  • Wie Einträge gespeichert und neu geladen werden

Tim betont hier wiederholt Geduld. Er bemerkt, dass Debugging langweilig erscheinen kann, aber vorschnelles Handeln führt oft dazu, dass Entwickler das eigentliche Problem übersehen.

Verwendung von bedingten Haltepunkten zur Eingrenzung von Fehlern

Nachdem aufgefallen ist, dass die Anwendung beim dritten Durchlauf einer Schleife abstürzt, demonstriert Tim eine fortgeschrittene Debugging-Technik: bedingte Haltepunkte.

Er setzt einen Haltepunkt, der nur dann ausgelöst wird, wenn die Trefferanzahl eine bestimmte Zahl erreicht. Dies ermöglicht ihm, bekannte gute Iterationen zu überspringen und sich direkt auf den fehlerhaften Fall zu konzentrieren.

Tim erklärt, dass diese Technik Zeit und geistige Energie spart, insbesondere in tief verschachtelten Schleifen.

Identifikation der Zyklischen Abhängigkeit

Schließlich identifiziert Tim die eigentliche Ursache des Stackoverflow. Er erklärt, dass die Anwendung in einer zirkulären Abhängigkeit feststeckt:

  • ConvertToMatchupEntryModels ruft ein Nachschlagen auf

  • Diese Abfrage lädt alle Begegnungen

  • Laden von Matchups ruft ConvertToMatchupEntryModels erneut auf

Tim hält inne und erklärt, dass dies geschieht, weil dateibasierte Speicherung nicht die Präzision einer Datenbank aufweist. In einer Datenbank können Sie einen einzelnen Datensatz anhand der ID abrufen. Aber hier lädt die Anwendung alles neu, einschließlich des aktuellen Eintrags, was eine unendliche Rekursion verursacht.

Fehlerbehebung: Endlosschleifen durch Begrenzung von Suchvorgängen

Tims Lösung besteht darin, die Strategie vollständig zu ändern. Anstatt alle Datensätze in Modelle umzuwandeln, er:

  • Lädt rohe Zeichenfolgen

  • Passt IDs direkt auf der Zeichenebene an

  • Konvertiert nur die erforderlichen Datensätze in Modelle

Er wendet dieses Muster konsequent an auf:

  • Matchup-Eintragssuchen

  • Teamsuchen

  • Matchup-Suchen

Tim erklärt, dass Muster die Freunde der Entwickler sind. Sobald ein Fix an einem Ort funktioniert, sollte er überall dort angewendet werden, wo dasselbe Problem besteht.

Umgang mit Formatierungsfehlern beim Speichern von Dateien

Nachdem die Endlosschleife gelöst ist, stößt Tim auf ein weiteres Problem - diesmal im Zusammenhang mit der Datei-Formatierung. Die Turnierdatendatei enthält unerwartete Zeilenumbrüche.

Tim bemerkt das Problem sofort: Dies ist der einzige Ort im Code, an dem mehrzeilige Zeichenfolgen (@"") verwendet werden. Er erklärt, dass das Debugging oft darin besteht, Unterschiede zu finden, nicht das, was gleich ist.

Er behebt das Problem, indem er die Speicherroutine umschreibt, um sicherzustellen, dass alles in einer Zeile geschrieben wird.

Letzter Fehler: Leere Zeichenfolgen und Schutzprüfungen

Beim Testen mit hinzugefügten Preisen stürzt die Anwendung erneut mit demselben "Eingabestring"-Fehler ab. Tim erklärt, dass Preis-IDs auch leere Zeichenfolgen sein können und das Parsen ohne Validierung eine weitere Ausnahme verursacht.

Sein Fix ist konsistent mit früherer Logik:

  • Prüfen der Stringlänge vor dem Parsen

  • Verarbeitung überspringen, wenn der Wert leer ist

Nach dieser Änderung läuft die Anwendung erfolgreich in mehreren Testszenarien.

Stresstests und Debugging-Mentalität

Tim beendet die Lektion mit der Betonung von Stresstests. Er erklärt, dass Entwickler bewusst versuchen sollten, ihre Anwendungen zu zerstören, indem sie:

  • Felder leer lassen

  • Ungültige Werte eingeben

  • Erwartete Schritte überspringen

Laut Tim bedeutet korrekte Fehlerbehandlung, dass die Anwendung elegant scheitern sollte, nicht abstürzen.

Er schließt mit der Ermutigung, dass Entwickler regelmäßig das Debugging üben sollten. Debugging, so erklärt Tim, geht nicht nur darum, Fehler zu beheben - es geht um Ermittlung, Geduld und das Verständnis, wie Ihr Code wirklich funktioniert.

Abschließende Gedanken

Diese Lektion zeigt, dass es beim C# WinForms-Fehlerhandling und Debugging nicht um Abkürzungen oder magische Fixes geht. Wie Tim Corey Schritt für Schritt demonstriert, geht es darum, das Verhalten zu beobachten, Breakpoints sinnvoll zu setzen, Annahmen zu testen und Probleme schichtweise zu beheben.

Debugging ist eine Fähigkeit, die durch Übung aufgebaut wird - und dieses Video ist ein kraftvolles Beispiel aus der Praxis, wie Profis es tun.

Hero Worlddot related to C# WinForms Fehlerbehandlung und Debugging — Ein tiefer Einblick mit Tim Corey
Hero Affiliate related to C# WinForms Fehlerbehandlung und Debugging — Ein tiefer Einblick mit Tim Corey

Verdienen Sie mehr, indem Sie teilen, was Sie lieben

Erstellen Sie Inhalte für Entwickler, die mit .NET, C#, Java, Python oder Node.js arbeiten? Verwandeln Sie Ihr Fachwissen in ein zusätzliches Einkommen!

Iron Support Team

Wir sind 24 Stunden am Tag, 5 Tage die Woche online.
Chat
E-Mail
Rufen Sie mich an