🏆Abschlussprojekt: Projekt: Die Grenzen der Fehlerbehandlung prüfen

Die Katalog-CLI hat jetzt eine sinnvolle Fehlerstruktur, nicht bloß mehr Ausnahmebehandlung. Jede Ebene bewahrt die Hinweise, für die sie zuständig ist:

• argparse lehnt ungültige Befehle vor der Konvertierung ab und verwendet Status 2;

• die Lesegrenze meldet erwartete Dateisystem-, Kodierungs-, CSV- und Schemafehler mit Status 1;

• Fehler bei der Auswahl gelangen mit ihrem ursprünglichen Traceback nach außen;

• die Schreibgrenze meldet ausschließlich Betriebssystemfehler mit Status 1;

• Validierungsfehler der Schreibfunktion gelangen mit ihrem ursprünglichen Traceback nach außen;

• Erfolg wird erst ausgegeben, nachdem eine angeforderte Datei geschrieben wurde.

Führe das fertige Projekt mit dem bereitgestellten Katalog aus:

python catalog.py catalog.csv selected.json --minimum-quantity 4
cat selected.json

Der Erfolgsvertrag bleibt gegenüber Kapitel 8 unverändert:

Wrote 2 items to selected.json.

Das JSON enthält BK-101 und PN-330 in Eingabereihenfolge. UTF-8-Text, Werttypen, Einrückung mit zwei Leerzeichen und ein abschließender Zeilenumbruch entsprechen weiterhin dem Dateivertrag aus Kapitel 7.

Einen erwarteten Fehler ausprobieren

Führe dieselbe gültige Befehlsform mit einer fehlenden Eingabedatei aus:

python catalog.py missing.csv selected.json --minimum-quantity 4

stdout bleibt leer. stderr beginnt mit Could not read missing.csv:, und der Prozess verwendet Status 1. Besonders wichtig: Dieser fehlgeschlagene Lesevorgang schreibt selected.json nicht neu. Mit cat kannst du die Datei erneut ansehen und das vorherige erfolgreiche Ergebnis sehen.

Diese Beobachtung ist enger als Transaktionssicherheit. Für einen späteren Ausgabefehler gibt es keine Zusage zur Rückabwicklung, weil die Schreibfunktion weiterhin direkt an ihren Pfad schreibt. Das Programm meldet die fehlgeschlagene Ausgabeoperation und behauptet keinen Erfolg, aber ein teilweise geschriebenes Ziel bleibt möglich.

Prüfen, dass dieselbe Ausnahme weiterhin Unterschiedliches bedeutet

In diesem Kapitel ging es darum, dass die Bedeutung einer Ausnahme von ihrer Herkunft abhängt, nicht nur von ihrer Klasse. Hier ist ein schneller Weg zu sehen, ob dein Code das tatsächlich berücksichtigt.

Ein ValueError beim Lesen einer beschädigten CSV-Zeile ist ein erwarteter Eingabefehler: Er sollte eine kurze Meldung und Status 1 erzeugen. Ein ValueError aus der eigenen Validierung der Schreibfunktion bedeutet, dass dein Code seiner eigenen Schreibfunktion etwas Ungültiges übergeben hat: Er sollte mit einem Traceback nach außen gelangen.

Dieselbe Ausnahmeklasse, entgegengesetzte Behandlung. Wenn beide denselben Weg nehmen, ist einer deiner try-Blöcke zu weit gefasst.

Probiere es aus. Füge vorübergehend am Anfang von write_catalog_json die Zeile raise ValueError("boom") ein, führe den Befehl aus und beobachte das Ergebnis. Du möchtest einen Traceback, keine ordentliche Kurzmeldung. Entferne die Zeile anschließend.

Tue dann dasselbe am Anfang von select_items. In dieser Befehlskette erhält die Auswahl validierte Daten im Speicher und greift auf nichts außerhalb des Programms zu. Ein Fehler dort zeigt deshalb einen Defekt an und sollte deutlich sichtbar bleiben.

Drücke Check my work, wenn sich die erfolgreiche Ergebnisdatei und beide Fehlergrenzen wie beschrieben verhalten.

Die praktische Gewohnheit in einem Satz: Reproduziere zuerst, lies die ursprünglichen Hinweise und fange nur dort ab, wo die fehlgeschlagene Operation eine Bedeutung hat, die du ehrlich benennen kannst.