- 1 Section
- 10 Lessons
- unbegrenzt
- Debugging & Fehleranalyse10
- 1.1Fehlertypen: Syntaxfehler, Laufzeitfehler, Logikfehler
- 1.2Systematische Fehlersuche: Duck-Debugging, Divide & Conquer
- 1.3Debugger-Grundkonzepte: Breakpoints, Watches, Call Stack
- 1.4Debugging in Java mit IntelliJ / Eclipse
- 1.5Debugging in Python mit VS Code und pdb
- 1.6Debugging in JavaScript: Browser DevTools
- 1.7Logging: Fehler protokollieren und auswerten
- 1.8Fehler in Datenbankabfragen finden
- 1.9Fehler in Netzwerkverbindungen und APIs debuggen
- 1.10Praxisaufgaben: Fehlerhafte Programme korrigieren
Debugging in Python mit VS Code und pdb
Wenn du in Python entwickelst, hast du zwei Hauptwege zum Debuggen: VS Code (heute der populärste Python-Editor, mit kostenlosem Python-Plugin) und pdb (Python's eingebauter Kommandozeilen-Debugger). VS Code für die Alltags-Arbeit mit GUI, pdb für SSH-Sessions auf Servern, Embedded-Umgebungen oder schnelle Inspektion ohne IDE.
Die Konzepte aus L3 gelten weiter – Breakpoints, Watches, Stepping, Call Stack. Python hat aber ein paar Eigenheiten: kein Compiler (Interpreter-Sprache), dynamische Typen (Bug-Quelle Nummer 1: ein None wo eine Liste sein sollte), und ein extrem mächtiges aber unscheinbares breakpoint()-Builtin.
1) VS Code als Python-IDE einrichten
Schnellster Weg: VS Code herunterladen, dann die Python-Extension von Microsoft installieren. Diese Extension bringt nicht nur Syntax-Highlighting, sondern auch einen vollständigen Debugger via debugpy (früher ptvsd).
Erste Schritte:
- Python-File öffnen (
script.py) - VS Code fragt: „Select Python interpreter" – wähle dein Python (Python 3.10+ empfohlen, oder dein venv)
- Klick links auf Zeilennummer = Breakpoint (roter Punkt)
- F5 = Debug starten → wähle „Python File" als Konfiguration
- Programm hält am Breakpoint, Debug-Panels erscheinen
Für komplexere Setups (Django, Flask, Pytest) erzeugst du eine launch.json im Ordner .vscode/. VS Code bietet Templates an. Beispiel für eine Flask-App:
2) VS Code Debugger live
Schauen wir einen Debug-Lauf an. Wir debuggen eine Funktion die einen Durchschnitt berechnen soll, aber einen Bug hat. Klick durch die Schritte:
total jeweils ändert – grün hervorgehoben. Bei Schritt 6 fällt auf: nach 3 Iterationen ist total nur 30 statt 60 (10+20+30). Da liegt der Bug: die Variable wird zwar zugewiesen, aber die Zuweisung benutzt nicht den vorherigen Wert (statt total += x nur total = x).3) VS Code Debug-Shortcuts
Die wichtigsten Tasten für effizientes Debugging:
| Aktion | Shortcut |
|---|---|
| Debug starten | F5 |
| Breakpoint toggle | F9 |
| Step Over (Zeile) | F10 |
| Step Into (Funktion) | F11 |
| Step Out (raus aus Funktion) | Shift+F11 |
| Continue | F5 |
| Stop Debug | Shift+F5 |
| Restart Debug | Strg+Shift+F5 |
Beachte: in VS Code sind die Step-Tasten F10/F11 – anders als in IntelliJ (F7/F8). Manche Entwickler die zwischen beiden wechseln, mappen die Bindings einheitlich – bekommt man in beiden IDEs hin.
4) Das breakpoint()-Builtin
Eine wenig bekannte aber sehr nützliche Python-Funktion seit Python 3.7: die eingebaute Funktion breakpoint(). Statt einen Breakpoint in der IDE zu setzen, schreibst du im Code:
Beim Erreichen dieser Zeile öffnet sich automatisch ein pdb-Prompt im Terminal (wenn ohne IDE) oder VS Code stoppt dort wie an einem regulären Breakpoint. Vorteil: du kannst Bedingungen direkt in den Code schreiben – wie ein Conditional Breakpoint im Code. Praktisch wenn du nach einem schwer reproduzierbaren Zustand suchst.
Vorsicht: breakpoint()-Aufrufe vor dem Commit unbedingt rausnehmen! Sonst geht dein Production-Server beim ersten Erreichen in den interaktiven Debug-Modus – das blockiert dort. Linter wie flake8-debugger warnen vor liegengebliebenen breakpoint()-Statements.
5) pdb – der Kommandozeilen-Debugger
pdb ist Pythons eingebauter Debugger. Kein Installer, keine Extension – ist immer dabei. Du startest ihn mit python -m pdb script.py oder ruft breakpoint() im Code auf. Im pdb-Prompt erscheinst du im interaktiven Modus mit dem berühmten (Pdb)-Prompt:
Die wichtigsten pdb-Befehle (alle haben Kurzformen):
b file.py:42 in anderer Datei.!x = 5 setzt Variable.ipdb (mit Syntax-Highlighting und Tab-Completion, pip install ipdb) und pudb (TUI-Interface mit Panels wie eine IDE).6) ipdb – pdb mit Komfort
Pdb ist roh – keine Farben, keine Auto-Completion. ipdb ist „pdb mit IPython-Power":
Im Code statt breakpoint():
Oder noch besser: setze die Umgebungsvariable PYTHONBREAKPOINT=ipdb.set_trace – dann nutzt das normale breakpoint()-Builtin automatisch ipdb. Das gibt dir die hübsche Variante ohne den Code anpassen zu müssen.
7) Python-spezifische Watch-Tipps
Da Python dynamisch typisiert ist, sind Watches besonders wichtig: du siehst nicht nur den Wert sondern auch den Typ. Bei einem Bug-Verdacht:
type(x)– ist x wirklich was du denkst?id(x)– ist es das gleiche Objekt oder ein anderes?len(x)– wie viele Elemente?dir(x)– welche Methoden/Attribute hat das Objekt?vars(x)– Dict der Instanz-Attributerepr(x)– ausführliche Darstellung (oft besser als str)
Diese fügst du in VS Code als Watch-Expressions hinzu: rechts im Debug-Panel das „+" bei „WATCH" klicken. Werte werden bei jedem Step neu evaluiert. Spart enorm viel Zeit gegenüber „immer wieder im Terminal eintippen".
8) Häufige Python-Bug-Sorten
Drei Bugs die besonders häufig in Python auftreten und wie du sie mit dem Debugger findest:
NoneType-Bug: AttributeError: 'NoneType' object has no attribute 'X'. Eine Funktion gibt None zurück, du erwartest aber ein Objekt. Im Debugger: setze Breakpoint vor der kritischen Stelle, schau ob die Variable wirklich was enthält. Häufige Ursache: vergessenes return in einer Funktion.
Mutable-Default-Argument: def func(items=[]). Die Liste wird EINMAL beim Funktions-Definieren erzeugt und über alle Aufrufe geteilt! Klassiker. Mit dem Debugger merkst du das schnell: die Liste hat schon Werte beim Funktions-Eintritt, obwohl du sie leer übergeben hast.
Late-Binding-Closure: bei lambda oder Funktion in Schleife wird die Schleifenvariable erst beim Aufruf gelesen, nicht beim Definieren. Sehr verwirrend: alle Lambdas haben am Ende den letzten Schleifenwert. Im Debugger sichtbar wenn du Funktionen einzeln aufrufst.
9) Logging als pdb-Ersatz
Manchmal ist ein interaktiver Debugger zu langsam oder unmöglich (Production, hochfrequente Schleifen, Multi-Threading). Dann nutzt du Logging:
Wann Logging statt Debugger? Wenn das Problem nicht reproduzierbar lokal ist, wenn es verteilt über mehrere Prozesse auftritt, wenn der Debugger das Timing verändert (Race Conditions!). Mehr zu strukturiertem Logging in L7.
10) PyCharm – die Alternative
JetBrains' PyCharm ist die Python-Variante von IntelliJ. Voller Debugger mit gleichen Konzepten – Conditional Breakpoints, Watches, Evaluate Expression, Stream-ähnliche Visualisierung für Generators. Tastatur-Kürzel sind wie IntelliJ (F8/F7/Shift+F8). Wer Java in IntelliJ debuggt und Python in PyCharm, hat einheitliche Bedienung. Für reine Python-Arbeit aber überdimensioniert – VS Code reicht meistens.
Zusammenfassung
Python-Debugging über VS Code (mit Python-Extension von Microsoft) oder pdb (eingebauter Kommandozeilen-Debugger). VS Code: Breakpoint links neben Zeile, F5 Debug starten, F10 Step Over, F11 Step Into. breakpoint()-Builtin (Python 3.7+) setzt Breakpoint direkt im Code. pdb-Befehle: l list, b N break, c continue, n next, s step, p VAR print, w stacktrace, q quit. ipdb für komfortableres pdb mit Tab-Completion und Farben (pip install ipdb). Watch-Tipps für Python: type(x), id(x), dir(x), vars(x) bei dynamischen Typen. Häufige Bugs: NoneType-AttributeError, Mutable-Default-Arguments, Late-Binding-Closures. Bei nicht-lokal-reproduzierbaren Bugs: Logging statt Debugger. PyCharm als Alternative – wie IntelliJ aber für Python. Mehr Python-Exceptions in K41.
