Python-Fehlerbehandlung: Versuchen Sie es mit / außer / sonst / endlich im Jahr 2026

Bei der Fehlerbehandlung wird zwischen „Code, der auf Ihrem Computer funktioniert“ und „Code, der die Produktion übersteht“ unterschieden. Pythons „try/exclusive“ sieht einfach aus, aber die vollständige Form mit vier Schlüsselwörtern – „try/exclusive/else/finally“ – kodiert überraschend viel Struktur, die in den meisten Tutorials übersprungen wird.

Dieser Leitfaden behandelt: Was jedes Schlüsselwort tatsächlich bedeutet, die sechs Muster, die Sie in jeder Backend-Codebasis sehen, wann Sie Ihre eigenen Ausnahmen definieren sollten und die drei Anti-Patterns, die Fehler an Ihren Tests vorbeischlüpfen lassen.

Genau die vier Schlüsselwörter

Die „else“-Klausel wird zu wenig verwendet. Es heißt: „Dieses nächste Bit hängt vom Erfolg des Versuchs ab, aber ich möchte nicht, dass es durch dasselbe geschützt wird, außer“. Es ist der richtige Ort für die Happy-Path-Fortsetzung – wenn Sie es in „try“ einfügen, werden versehentlich nicht verwandte Ausnahmen von „ship(result)“ abgefangen.

Die sechs Muster

1. Bei vorübergehendem Fehler erneut versuchen

Regel: Versuchen Sie es NUR bei vorübergehenden Fehlern (Netzwerk, Zeitüberschreitung, 429, 503). Versuchen Sie es niemals erneut bei „ValueError“, „KeyError“, „TypeError“ – das sind Codefehler, und ein erneuter Versuch führt den Fehler nur dreimal aus.

2. Mit „else“ schützen

Das „else“ garantiert, dass „file“ erfolgreich geöffnet wurde UND schließt die Bereinigung mit „with“ ein. Hinweis: „process()“ könnte „ValueError“ auslösen – dieser wird weitergegeben und NICHT von „außer FileNotFoundError“ abgefangen.

3. Aufräumen mit „finally“ (bevor „with“ existierte)

In modernem Code würden Sie „with db.connect() as conn:“ verwenden – „with“ ist der Zucker über „try/finally“ für den allgemeinen Bereinigungsfall. Greifen Sie nach explizitem „finally“ nur dann, wenn die Ressource das Kontextmanager-Protokoll nicht unterstützt.

4. Erneut mit zusätzlichem Kontext ansprechen

„raise NewException(...) from e“ verkettet die ursprüngliche Ausnahme mit der neuen, sodass der Traceback BEIDE anzeigt. Schreiben Sie niemals „raise NewException(str(e))“ – das verwirft den ursprünglichen Traceback.

5. Fangen Sie die engste Ausnahme ab, die Sie können

Regel: Je schmaler die Ausnahme, desto besser. Wenn Sie nicht wissen, was ein „Prozess“ auslösen kann, führen Sie ihn aus und finden Sie es heraus. „außer Ausnahme:“ ist in 90 % der Fälle ein Codegeruch.

6. „Raise“ innerhalb von „außer“ – sauber erneut erhöhen

Durch bloßes „Raise“ bleibt der ursprüngliche Traceback erhalten. Erhöhen Sie niemals e (Python 3 ist darin schlau, aber bloßes „Raise“ ist die idiomatische Form).

Benutzerdefinierte Ausnahmen – wenn es sich lohnt

Definieren Sie Ihre eigene Ausnahmeklasse, wenn:

1. Aufrufer müssen speziell „MyError:“ ausnehmen (d. h. Sie haben eine aufrufbare API und Benutzer müssen nach Fehlertyp verzweigen).

2. Ihre Bibliothek/Ihr Dienst löst mehrere verwandte Fehler aus, die den gleichen Kontext haben.

Jetzt können Anrufer grob („außer PaymentError“) oder eng („außer CardDeclinedError“) abfangen. Strukturierte Attribute für die Ausnahme („e.card_last4“) ermöglichen es Fehlerhandlern, nützliche UX zu erstellen, ohne Ausnahmemeldungen zu analysieren.

Anti-Muster: Definiert eine benutzerdefinierte Ausnahme, die nur einmal ausgelöst und nie abgefangen werden kann. Das ist nur raise ValueError("..."). Benutzerdefinierte Ausnahmen verdienen ihr Gewicht dadurch, dass sie abgefangen werden.

Drei Anti-Patterns, die Fehler verbergen

Anti-Muster 1: Bloß, außer

Bloßes „außer“ fängt Signale ab, die das Programm beenden sollen (Strg-C, „sys.exit“, „MemoryError“). Schreiben Sie das niemals. Wenn Sie wirklich jede nicht schwerwiegende Ausnahme abfangen möchten, verwenden Sie „außer Ausnahme:“ – was IMMER NOCH zu viel abfängt, aber zumindest Strg-C respektiert.

Anti-Pattern 2: Stummschaltung ohne Protokollierung

Jede abgefangene Ausnahme sollte entweder behandelt (mit einem bestimmten Fallback) oder protokolliert werden. „pass“ in einer Ausnahme ist ein Fehler in Zeitlupe – der Code scheint zu funktionieren, während Daten stillschweigend verworfen werden.

Anti-Muster 3: „außer Ausnahme:“ um alles herum

Problem: Wenn „stripe.charge“ erfolgreich war, „send_receipt“ jedoch fehlschlug, wurde dem Kunden eine Gebühr berechnet UND Sie haben den Fehler verschluckt. Die „Ausnahme“ deckt vier verschiedene Fehlermodi ab, die man nicht unterscheiden kann.

Fix: Den Try-Bereich einschränken und das Except nach Modulgrenze verzweigen.

Jeder Versuch umfasst EINEN Vorgang. Jeder außer weiß, was bei DIESEM spezifischen Fehler zu tun ist. Das ist Fehlerbehandlung auf Produktionsniveau.

Bei einer guten Fehlerbehandlung geht es mehr um Design als um Syntax. „try/except/else/finally“ gibt Ihnen die Werkzeuge; Die Disziplin besteht darin, den richtigen außer Typ auszuwählen, den Testumfang so eng wie möglich zu halten und Fehler, die Sie nicht verstehen, niemals zum Schweigen zu bringen.

Nächster Schritt: Der Foundations-Track führt Sie durch die Ausnahmebehandlung, benutzerdefinierte Ausnahmen und die „with“-Anweisung – mit echtem Python, das in Ihrem Browser ausgeführt wird.