Antwoord.

Achtergrond:

Het uitzonderingensysteem (exceptions) is vanaf het begin in Python aanwezig en is gebaseerd op klassen. De gehele hiërarchie van uitzonderingen is afgeleid van de basis klasse BaseException. In de praktijk worden eigen uitzonderingen gemaakt van Exception. Het ontwikkelen van gebruikerspecifieke uitzonderingen is belangrijk voor grote projecten — het stelt je in staat om specifieker om te gaan met en te signaleren van specifieke fouten in de applicatie.

Probleem:

Niet alle ontwikkelaars begrijpen de verschillen tussen BaseException en Exception, ze zijn te lui om hun eigen klassen te creëren, gebruiken algemene catch-blokken, wat leidt tot het opvangen van ongewenste uitzonderingen (bijvoorbeeld, SystemExit, KeyboardInterrupt) en moeilijk te traceren bugs. Vaak worden uitzonderingsklassen onjuist geïmplementeerd — ze geven geen betekenisvolle naam op en erft niet van de juiste klasse.

Oplossing:

Maak je eigen uitzonderingen als afstammelingen van Exception. Gebruik betekenisvolle namen, zodat je niet basale fouten overal vangt. Erf niet van BaseException, maar alleen van Exception of zijn afgeleiden, en vang niet alles met except: zonder een specifieke klasse aan te geven.

Voorbeeldcode:

class MyAppError(Exception):
    """Basis klasse voor applicatie-uitzonderingen"""
    pass

class ConfigFileNotFound(MyAppError):
    pass

try:
    raise ConfigFileNotFound('Configuratiebestand niet gevonden!')
except ConfigFileNotFound as e:
    print(f'Fout: {e}')

Belangrijke punten:

Gebruikerspecifieke uitzonderingen moeten altijd afstammen van Exception.
Vang geen uitzonderingen van het type BaseException (bijvoorbeeld, KeyboardInterrupt) — dit zijn systeemgebeurtenissen.
Uitzonderingen kunnen handig worden gegroepeerd in hiërarchieën voor fijnmazigere afhandeling.

Sneaky vragen.

Wat is het gevaar van het vangen van alle uitzonderingen met "except:" zonder typeaanduiding?

Dit blok vangt zelfs systeemuitzonderingen — KeyboardInterrupt, SystemExit, waardoor het onmogelijk wordt om normaal een programma te beëindigen bij Ctrl+C en leidt tot "bevriezing" in kritieke situaties. Je moet "except Exception:" schrijven om basale systeemgebeurtenissen over te slaan.

Is het mogelijk om je eigen uitzondering van BaseException te laten erven?

Technisch gezien kan dat, maar het wordt ten zeerste afgeraden — dergelijk uitzonderingen zijn moeilijk te detecteren, ze omzeilen de standaard Exception-handlers, wat vaak leidt tot onoplosbare fouten in de applicatie.

Is het juist om ValueError of TypeError te gebruiken in plaats van gebruikerspecifieke uitzonderingen?

In kleine scripts is het acceptabel, maar in grote projecten is het beter om je eigen semantisch betekenisvolle uitzonderingen te maken. Dit versnelt de diagnostiek en afhandeling van fouten op hogere niveaus van de applicatie.

# Onjuist:
raise ValueError('Iets specifieks voor de applicatie')
# Goed:
class MyAppValueError(MyAppError):
    pass
raise MyAppValueError('Omschrijving van de fout met de context van de applicatie')

Typische fouten en anti-patronen

Vangen van uitzonderingen zonder type aanduiding (except:)
Importeren van externe uitzonderingen met onduidelijke erfenis
Constructeurs van foutklassen zonder aanroep van super().init (verlies van bericht)

Voorbeeld uit het leven

Negatieve casus

In een groot project was er een globale try/except: blok die ook systeemuitzonderingen ving. Een aantal fouten (bijvoorbeeld, SystemExit) werd niet in de log weergegeven, de applicatie ging in onverwachte toestanden, en de beheerders zochten lang naar symptomen.

Voordelen:

Het systeem "viel" niet door zeldzame fouten.

Nadelen:

Moeilijkheid bij het zoeken naar de oorzaak van de storing.
Onverwachte blokkeringen, onmogelijkheid tot normaal beëindigen.

Positieve casus

Eigen foutklassen werden gedefinieerd, er werd alleen "except Exception: ..." gebruikt en afzonderlijke handlers voor gebruikerspecifieke uitzonderingen.