🏆Eindproject: Project: toon de grenzen van foutafhandeling aan

De catalogus-CLI heeft nu een bruikbare indeling van fouten, niet alleen meer exceptieafhandeling. Elke laag bewaart het bewijs waarvoor die verantwoordelijk is:

• argparse wijst ongeldige commando’s vóór de conversie af en gebruikt status 2;

• de grens rond het lezen meldt verwachte fouten in bestandssysteem, codering, CSV en schema met status 1;

• defecten in de selectie gaan verder met hun oorspronkelijke traceback;

• de grens rond het schrijven meldt alleen besturingssysteemfouten met status 1;

• validatiedefecten van de schrijver gaan verder met hun oorspronkelijke traceback;

• succes wordt pas afgedrukt nadat een gevraagd uitvoerbestand is geschreven.

Voer het voltooide project uit op de meegeleverde catalogus:

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

Het succescontract is hetzelfde als in hoofdstuk 8:

Wrote 2 items to selected.json.

De JSON bevat BK-101 en PN-330 in invoervolgorde. De UTF-8-tekst, waardetypen, inspringing met twee spaties en één afsluitend regeleinde volgen nog steeds het bestandscontract uit hoofdstuk 7.

Probeer één verwachte fout

Voer dezelfde geldige commandovorm uit met een ontbrekend invoerbestand:

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

stdout blijft leeg. stderr begint met Could not read missing.csv: en het proces gebruikt status 1. Het belangrijkste is dat selected.json door deze mislukte leesbewerking niet wordt herschreven. Je kunt het opnieuw met cat bekijken om het eerdere geslaagde resultaat te zien.

Die waarneming bewijst minder dan transactieveiligheid. Een latere uitvoerfout heeft geen garantie op terugdraaien, want de schrijver schrijft nog steeds rechtstreeks naar zijn pad. Het programma meldt de mislukte uitvoerbewerking en beweert geen succes, maar een gedeeltelijk geschreven doelbestand blijft mogelijk.

Controleer of dezelfde exceptie nog steeds verschillende dingen betekent

De kern van dit hoofdstuk was dat de betekenis van een exceptie afhangt van waar ze vandaan komt, niet alleen van haar klasse. Zo kun je snel zien of je code dat daadwerkelijk respecteert.

Een ValueError tijdens het lezen van een beschadigde CSV-rij is een verwachte invoerfout: die hoort een korte melding en status 1 op te leveren. Een ValueError uit de validatie van je eigen schrijver betekent dat je code iets ongeldigs aan haar eigen schrijver gaf: die hoort verder te gaan met een traceback.

Dezelfde exceptieklasse. Tegengestelde behandeling. Als beide dezelfde route volgen, is een van je try-blokken te breed.

Probeer het. Voeg tijdelijk raise ValueError("boom") bovenaan write_catalog_json toe, voer het commando uit en kijk wat er gebeurt. Je wilt een traceback, geen nette melding. Verwijder de regel daarna.

Doe vervolgens hetzelfde bovenaan select_items. In deze reeks bewerkingen krijgt de selectie gevalideerde gegevens in het geheugen en raakt ze niets buiten het programma. Een fout daar wijst dus op een defect en hoort duidelijk zichtbaar te blijven.

Klik op Check my work wanneer het geslaagde uitvoerbestand en beide grenzen voor foutafhandeling zich gedragen zoals beschreven.

De praktische gewoonte past in één zin: reproduceer eerst, lees het oorspronkelijke bewijs en vang alleen op waar je de betekenis van de mislukte bewerking eerlijk kunt benoemen.