Wie entscheidest du, wo du Exceptions fängst und was du mit ihnen machst?

Fang eine Exception nur dort, wo du tatsächlich etwas tun kannst: neu versuchen, einen Default einsetzen oder sie mit Kontext in einen Domänenfehler übersetzen. Überall sonst lässt du sie bis zu einer einzigen Grenze durchlaufen, die loggt und eine Antwort zurückgibt. Fang spezifische Typen statt eines nackten except, schluck nie still, und nutz raise from, damit die ursprüngliche Ursache im Traceback überlebt.

Mein Default ist, Dinge durchlaufen zu lassen. Ein try except ist nur gerechtfertigt, wenn ich neu versuchen, auf etwas Sinnvolles zurückfallen oder Kontext ergänzen kann, den der Aufrufer braucht. Sonst verstecke ich nur Information. In Services baue ich das als eine Fehlergrenze, meist Middleware oder ein Exception Handler, die den vollen Traceback mit Request-ID loggt und eine saubere Antwort zurückgibt, und der Code darunter bleibt lesbar, weil er nicht mit Handlern behängt ist. Innerhalb eines Moduls fange ich enge Typen und übersetze sie mit raise from in eine Domänen-Exception, damit der Traceback die ursprüngliche Ursache behält, denn dieses Verlieren der Kette ist der Grund, warum man am Ende auf einen Stacktrace starrt, der nirgends Sinnvollem beginnt. Nacktes except ist in den Codebases, die ich verantworte, verboten, weil es auch KeyboardInterrupt und SystemExit schluckt. Die Unterscheidung, die mir am wichtigsten ist, ist erwarteter Fehler gegen Bug. Ein Timeout bei einer Drittanbieter-API ist erwartet und wird wiederholt. Ein KeyError auf meinem eigenen Dictionary ist ein Bug und soll laut sein.