Praxisaufgaben: Fehlerhafte Programme korrigieren

Zeit für die Praxis. In den vorherigen neun Lektionen hast du die Theorie gelernt: Fehlertypen, Methodik, Debugger-Konzepte, sprachspezifische Werkzeuge für Java, Python und JavaScript, plus Logging, DB-Debugging und API-Diagnose. Jetzt setzen wir das alles an realen Bug-Szenarien ein.

Diese Lektion enthält 8 Bug-Hunts unterschiedlicher Schwierigkeit. Schau dir jeweils den Code an, überlege was schief ist, dann klick auf „Lösung anzeigen". Versuche es erst ohne Lösung – das Lernen passiert beim selbst-Denken. Die Schwierigkeit reicht von EASY (Syntax-Fehler in 30 Sekunden zu finden) bis HARD (subtile Logikfehler die dich in der Praxis Stunden kosten würden).

1) Dein mentaler Workflow

Bei jedem Bug-Hunt durchläufst du intern dieselbe Sequenz die wir in L2 kennengelernt haben:

Was tut der Code soll? (Lies den Code, lies den erwarteten Output)
Was tut er tatsächlich? (Lies den fehlerhaften Output)
Welcher Fehlertyp? (Syntax, Laufzeit, Logik – aus L1)
Hypothese: wo könnte die Diskrepanz herkommen?
Wo würde ich einen Breakpoint setzen / einen print einbauen?

Erst dann nach unten klicken. Die ersten Übungen sind einfach – das ist Absicht. Du sollst den Workflow verinnerlichen.

2) Bug-Hunt 1: Off-by-One

Klassischer Fehler bei Schleifen über Zahlenbereiche. Sieht harmlos aus, Ergebnis ist trotzdem falsch:

BUG #1 — Python EASY

Funktion soll Summe der Zahlen 1 bis n berechnen.

sum_to.py

1def sum_to(n):
2    total = 0
3    for i in range(n):
4        total += i
5    return total
6
7print(sum_to(10))

Tatsächlich

Erwartet

55 (= 1+2+3+...+10)

Diagnose:

Klassischer Off-by-One-Fehler (siehe L1). range(n) in Python liefert die Zahlen 0 bis n-1, also 0,1,2,...,9. Die Summe ist 45, nicht 55.

Fix: range(1, n+1) – liefert 1 bis n inclusive.
Such-Strategie: Eine Zeile mit print(i) in der Schleife → du siehst sofort 0,1,2,...,9 statt 1,...,10. Im Debugger: Breakpoint in Zeile 4, Watch auf i, ein paar Iterationen durchsteppen.

3) Bug-Hunt 2: NullPointer

Eine Java-Methode soll robust mit null umgehen – tut es aber nicht. Crash bei jedem zweiten Aufruf:

BUG #2 — Java EASY

Methode soll User-Name oder "Anonymous" wenn user null.

UserService.java

1public String getName(User user) {
  String name = user.getName();
  if (name.isEmpty() || user == null) {
      return "Anonymous";
  }
  return name;
7}

Stacktrace

java.lang.NullPointerException: Cannot invoke "User.getName()" at UserService.getName(UserService.java:2)

Diagnose:

Reihenfolge der Bedingungen ist falsch. Zeile 2 ruft user.getName() auf – aber wenn user null ist, crashed das schon hier. Der null-Check kommt zu spät.

Fix:

Behoben

1if (user == null) return "Anonymous";
2String name = user.getName();
3return name == null || name.isEmpty() ? "Anonymous" : name;

Take-away: Null-Checks immer ZUERST. Auch name kann null sein – nicht nur leer.

4) Bug-Hunt 3: String-Vergleich in Java

BUG #3 — Java MEDIUM

Passwort-Vergleich, sehr einfach.

1public boolean checkLogin(String userInput, String stored) {
2    if (userInput == stored) {
3        return true;
4    }
5    return false;
6}

Tatsächlich

checkLogin("geheim", "geheim") → false (!?)

Diagnose:

Klassischer Java-Strings mit ==-Operator-Bug. In Java vergleicht == bei Objekten die Referenz, nicht den Inhalt. Zwei String-Variablen können denselben Inhalt haben aber unterschiedliche Objekte sein – == ist dann false.

Tückisch: wegen String-Interning bei Literalen ("hello" == "hello" ist oft true) übersehen Anfänger den Bug. Bei Strings aus User-Input, DB oder Netzwerk klappt es plötzlich nicht.

Fix:

Behoben

1return userInput != null && userInput.equals(stored);

Sicherheits-Note: Bei echten Passwörtern niemals naiv vergleichen – auch nicht mit equals(). Stattdessen MessageDigest.isEqual() für Timing-Attack-Sicherheit. Mehr in K11 Secure Coding.

5) Bug-Hunt 4: Mutable Default

Ein Klassiker den jeder Python-Entwickler mindestens einmal erlebt. Sieht völlig harmlos aus:

BUG #4 — Python MEDIUM

Funktion zum Anlegen eines Users mit optionalen Rollen.

Beim zweiten Aufruf ohne Rollen tauchen plötzlich Rollen des ersten Users auf:

users.py

1def create_user(name, roles=[]):
2    roles.append('user')
3    return {'name': name, 'roles': roles}
4
5u1 = create_user('Anna', ['admin'])
6u2 = create_user('Bob')
7u3 = create_user('Clara')
8print(u2); print(u3)

Tatsächlich

{'name': 'Bob', 'roles': ['user']} {'name': 'Clara', 'roles': ['user', 'user']} ← !?

Erwartet

{'name': 'Bob', 'roles': ['user']} {'name': 'Clara', 'roles': ['user']}

Diagnose:

Mutable Default Argument – einer der bekanntesten Python-Bugs. Die Default-Liste [] wird einmal beim Funktions-Definieren erzeugt und über alle Aufrufe geteilt. Bei Bob wird "user" angefügt – die geteilte Liste ist jetzt ['user']. Bei Clara wird wieder angefügt – jetzt ['user','user'].

Fix:

Behoben

1def create_user(name, roles=None):
  if roles is None:
      roles = []
  roles.append('user')

Such-Strategie: Schwer per Debugger – subtil. Erkennbar wenn man id(roles) zwischen Aufrufen vergleicht: dieselbe ID! Linter wie pylint warnen mit dangerous-default-value.

6) Bug-Hunt 5: SQL-NULL

Ein subtiler SQL-Bug der fast jeden Entwickler einmal erwischt:

BUG #5 — SQL MEDIUM

Alle User finden, die KEINE Premium-Mitgliedschaft haben.

In der DB: 1000 User mit role=NULL (registriert aber nie aktiviert), 200 mit role='premium'. Query gibt 0 Zeilen:

query.sql

1SELECT * FROM users WHERE role != 'premium';

Tatsächlich

0 Zeilen

Erwartet

1000 Zeilen (die mit NULL-Role)

Diagnose:

NULL-Falle – siehe L8. In SQL liefert NULL != 'premium' NICHT true, sondern UNKNOWN. UNKNOWN-Treffer fliegen aus dem Filter raus. Drei-wertige Logik!

Fix:

Behoben

1SELECT * FROM users WHERE role != 'premium' OR role IS NULL;

Alternativ mit COALESCE(role, '') != 'premium'.

7) Bug-Hunt 6: Race Condition

Funktioniert im Test perfekt, in Production stimmen die Zahlen plötzlich nicht. Sehr typisch für Threading-Bugs:

BUG #6 — Java HARD

Request-Counter. Sollte 50 zählen bei 50 parallelen Requests.

Im Production-Test mit 50 parallelen Threads: zählt nur 30 oder 35:

RequestCounter.java

1public class RequestCounter {
2    private int count = 0;
3
4    public void increment() {
5        count++;
6    }
7
8    public int getCount() { return count; }
9}

Diagnose:

Race Condition. count++ ist KEIN atomarer Befehl – es sind drei Schritte: 1) read count, 2) add 1, 3) write back. Wenn zwei Threads gleichzeitig read'en (beide lesen 5), beide add'en 1 (beide haben 6), beide schreiben zurück (beide schreiben 6) – aber wir hätten 7 erwartet. Ein Increment ist verloren.

Fix-Optionen:

Option A: synchronized

1public synchronized void increment() { count++; }

Option B: AtomicInteger (besser)

1private AtomicInteger count = new AtomicInteger();
2public void increment() { count.incrementAndGet(); }

Such-Strategie: Schwer per Debugger – Race Conditions verschwinden oft beim Debuggen (Heisenbug! Siehe L1). Diagnose: Logging jeder Increment-Operation mit Thread-ID. Oder Stress-Test schreiben der das reproduziert. Mehr zu Threading in K40b.

8) Bug-Hunt 7: Async/forEach

JavaScript-async-Bug: User-Daten parallel holen sieht einfach aus – ist es nicht:

BUG #7 — JavaScript HARD

User-Daten von 3 verschiedenen IDs holen und sammeln.

fetchUsers.js

1async function fetchUsers(ids) {
2    const users = [];
3    ids.forEach(async (id) => {
4        const r = await fetch(`/api/users/${id}`);
5        users.push(await r.json());
6    });
7    return users;
8}
9
10fetchUsers([1,2,3]).then(console.log);

Tatsächlich

[]

Erwartet

[ {id:1,...}, {id:2,...}, {id:3,...} ]

Diagnose:

forEach erwartet keine async-Funktion und wartet nicht auf sie. Die forEach-Schleife läuft sofort durch, alle drei async-Callbacks starten – aber fetchUsers kehrt zurück bevor sie fertig sind. users ist noch leer.

Fix mit Promise.all (parallel und schnell):

Behoben

1const users = await Promise.all(
2    ids.map(async (id) => {
3        const r = await fetch(`/api/users/${id}`);
4        return r.json();
5    })
6);

Im Network-Tab siehst du dass die Requests starten – im Debugger siehst du dass return users mit leerem Array passiert (Step Over über die forEach hinaus). Lehre: forEach + async = (fast) immer falsch.

9) Bug-Hunt 8: Zeitzone

Letzter Bug, fies subtil. Funktioniert lokal, schlägt erst nach dem Deploy auf einem US-Server fehl:

BUG #8 — Python HARD

Tagesübersicht. Holt Orders von „heute".

Funktioniert lokal in Berlin. Nach Deploy auf US-Server (UTC): Berliner Nutzer sehen abends 22:30 Uhr noch die Orders von gestern – als wäre der Tag nicht da:

daily_summary.py

1from datetime import date
2
3def orders_today():
4    today = date.today()
5    return db.query(
6        "SELECT * FROM orders WHERE DATE(created_at) = ?",
7        today)

Diagnose:

Zeitzonen-Bug. date.today() liefert das Datum in der Server-Zeitzone. Bei einem US-Server ist UTC um 22:30 Berliner Zeit = 20:30 UTC – also noch derselbe Tag. Aber wenn es 02:00 Berliner Zeit ist (= 00:00 UTC), denkt der Server schon „neuer Tag" während die Berliner noch in der „alten" Nacht sind. Symmetrisch andersrum.

Außerdem: created_at in der DB ist vermutlich auch ohne Zeitzone gespeichert – Datum-Vergleich zwischen unklaren Zeitzonen ist immer ein Bug.

Fix:

Behoben

1from datetime import datetime, timezone
2from zoneinfo import ZoneInfo
3
4def orders_today(user_tz='Europe/Berlin'):
5    tz = ZoneInfo(user_tz)
6    now_user = datetime.now(tz)
7    start = now_user.replace(hour=0, minute=0, second=0)
8    end = start.replace(hour=23, minute=59, second=59)
9    return db.query(
10        "SELECT * FROM orders WHERE created_at BETWEEN ? AND ?",
11        start, end)

Faustregeln: Server intern immer in UTC. Beim Anzeigen User-Timezone berücksichtigen. datetime.now() ohne Argument vermeiden – immer mit tz. DB-Spalten am besten als TIMESTAMPTZ (PostgreSQL) speichern.

10) Was wir gelernt haben

Du hast jetzt acht typische Bug-Klassen durch – das ist ein riesiger Teil dessen was du in der Praxis siehst. Jeder dieser Bugs hat uns auch eine Werkzeug-Lektion gezeigt:

Bug	Such-Werkzeug
Off-by-One	Print/Watch in der Schleife
NullPointer	Stacktrace lesen, null-Checks reviewen
String == in Java	identityHashCode-Watches
Mutable Default	Linter / `id()`-Vergleich
SQL NULL	Subset-Tests in SQL-Konsole
Race Condition	Stress-Tests + Logging mit Thread-ID
Async forEach	Step durch async-Code im Debugger
Zeitzonen	Werte mit Timezone loggen

11) Skill-Tree: was du beherrschst

Nach diesem Kurs solltest du folgende Skills auf der Hand haben:

Dein Debugging-Skill-Tree

✓ Fehler klassifizieren

Syntax, Laufzeit, Logik unterscheiden

✓ Systematisch suchen

7-Schritte-Methode, Bisection, Duck

✓ Debugger nutzen

Breakpoints, Watches, Stack, Stepping

✓ IntelliJ

Java mit allen Features

✓ VS Code + pdb

Python lokal und im Terminal

✓ Chrome DevTools

JavaScript und Network

✓ Logging-Levels

FATAL bis TRACE, strukturiert

✓ SQL-Debugging

EXPLAIN, Subset-Tests, NULL-Fallen

✓ API-Diagnose

curl, Network-Tab, HTTP-Codes

✓ Stacktraces lesen

Den Stack richtig interpretieren

✓ Bug-Patterns

8 Klassiker erkannt + gefixt

✓ Root-Cause

5-Whys, nicht nur Symptom fixen

12) Was als nächstes?

Mit diesen Skills bist du im Debugging gut aufgestellt. Trotzdem gibt es immer mehr zu lernen. Sinnvolle Vertiefungen:

Performance-Profiling: über reines Funktional-Debugging hinaus. Tools wie VisualVM, py-spy, Chrome Performance-Tab.
Memory-Leak-Hunting: Heap-Dumps, Profiler, GC-Logs. Eigenes Themengebiet.
Distributed-Tracing: bei Microservices, mit Jaeger/Zipkin/OpenTelemetry.
Test-Driven Development: viele Bugs passieren gar nicht erst wenn man vorher Tests schreibt. Mehr in K54 CI/CD.
Static Analysis: SonarQube, ESLint, SpotBugs finden viele Bugs ohne dass du sie laufen lassen musst.
Chaos Engineering: gezielt Fehler einbauen um die Resilience zu testen. Netflix-Klassiker.

Die größte Empfehlung: übe. Jeder echte Bug den du selbst löst ist mehr wert als zehn theoretische Lektionen. Vermeide den Reflex sofort den Kollegen zu fragen – versuche es erst selbst mit der Methodik. Nach ein paar Wochen merkst du wie schnell du wirst.

Zusammenfassung

8 typische Bug-Klassen aus der Praxis durchgegangen, von EASY bis HARD: Off-by-One (range(n) liefert 0..n-1), NullPointer durch falsche Reihenfolge (null-Check muss erste sein), String-Vergleich mit == in Java (equals nutzen, Strings sind Objekte), Mutable Default Argument in Python (geteilte Liste über Aufrufe), SQL-NULL-Falle (Three-Valued Logic), Race Condition in Threading (count++ ist nicht atomar), forEach + async in JavaScript (wartet nicht), Zeitzonen (UTC vs. lokal). Jeder Bug demonstriert eine andere Such-Strategie: Print in Schleifen, Stacktrace lesen, identityHashCode-Watches, Linter, Subset-Tests, Stress-Tests, Step-by-Step Async, Werte mit Timezone loggen. Methodischer Workflow: Soll vs. Ist verstehen, Fehlertyp klassifizieren, Hypothese, gezielte Diagnose, Fix, Regression-Test, 5-Whys. Skill-Tree nach diesem Kurs: Fehler klassifizieren, systematisch suchen, Debugger nutzen, IDE-spezifische Werkzeuge für Java/Python/JS, Logging, SQL, APIs, Stacktraces, Bug-Patterns, Root-Cause-Analyse. Nächste Schritte: Performance-Profiling, Memory-Leaks, Distributed Tracing, TDD, Static Analysis, Chaos Engineering. Üben ist die wichtigste Empfehlung – jeder echte Bug, den du selbst löst, ist mehr wert als zehn Lektionen.

Praxisaufgaben: Fehlerhafte Programme korrigieren

1) Dein mentaler Workflow

2) Bug-Hunt 1: Off-by-One

3) Bug-Hunt 2: NullPointer

4) Bug-Hunt 3: String-Vergleich in Java

5) Bug-Hunt 4: Mutable Default

6) Bug-Hunt 5: SQL-NULL

7) Bug-Hunt 6: Race Condition

8) Bug-Hunt 7: Async/forEach

9) Bug-Hunt 8: Zeitzone

10) Was wir gelernt haben

11) Skill-Tree: was du beherrschst

12) Was als nächstes?

Zusammenfassung

Anmelden

Account Registrieren und Fortschritt Speichern!

Modal title