Wir hatten schon diverse Diskussionen zum Thema 'Exceptions: Geißel oder Segen?'. Oder auch: 'Oute ich mich als Versager, wenn ich mit Try..Except arbeite'.
Ich werde mal wieder meine Meinung zum Besten geben:
Ein Grundsatz robuster Softwareentwicklung ist, das innere Exceptions nicht nach außen dringen sollen. Ich muss also *alle* Exceptions abfangen, behandeln und ggf. in andere Exceptions übersetzen. Jede öffentliche Klasse sollte auch einen Satz von eigenen Exceptions mitbringen, in die die inneren Exceptions ggf. übersetzt werden.
Was bringt dem Anwender eine
Exception der
TCP-Klasse? Er versteht sie nicht, er wollte mit
TCP nix am Hut haben, also: Gar nichts. Ihm ist es auch egal, das der Programmierer einen
SQL-Befehl falsch geschrieben hat. Er will klare und verständliche Fehlermeldungen. in der Logdatei kann der Fehler ja stehen, aber nicht auf dem Bildschirm.
Für mich (und u.A. auch die Erfinder moderner Programmiersprachen) sind Try-Except Blöcke ein Segen, denn sie erlauben mir, einen klaren Programmfluss, der eben nicht durch ständige Abfragen von Präkonditionen unleserlich gemacht wird. Denn Eine
Exception ist die Ausnahme, der Code wird also i.d.R. so abgearbeitet, wie ich es wollte, nur eben in Ausnahmen nicht. Die sind i.d.R. gravierend und führen dann zum Abbruch der Aktion.
D.h. natürlich nicht, das ich auf sämtliche Präkonditionen verzichte, aber da ich sowieso nicht alle Fehler von vorne herein abfangen kann, beschränke ich mich auf die, die den Code leserlicher machen.
Beispiel: Ich kann schauen, ob eine Datei, aus der ich lesen will, existiert. Aber wozu soll ich vorher prüfen, ob die Datei korrupt ist? Da lass ich den Karren doch lieber an die Wand fahren und kratze die überbleibsel ab und analysiere sie.
Gut, Try-Except macht also Sinn. Alle sichtbaren Methoden sind mit einem Try-Except-Block gekapselt, und sei es, um die Logdatei zuzumüllen.
Das ich zudem in den meisten Methoden irgendwelche Klassen instantiiere, die ich im Finally-Block wieder freigebe, folgt daraus, das alle Methoden nach dem Motto: Reservieren-Ausführen-Fehler behandeln-Freigeben implementiert werden.
Delphi-Quellcode:
Try
...
Except
LogDenFehler;
Finally // << --- unnötig
WaschDieHände;
End;
Ist hübsch aber überflüssig, denn der Fehler wird nicht weitergereicht, also braucht man auch den Finally-Block nicht.
Ich konvertiere Fehler und leite sie weiter, denn Fehler sind schwerwiegend und keine Bagatelldelikte. Also wäre mir ein kompakter Try-Except-Finally-Block angenehm.
Delphi-Quellcode:
Try
...
Except
LogDenFehler;
LeiteIhnWeiter; // <<---
Finally
WaschDieHände;
End;
Ich nehme mal an, die Java- und C#-Erfinder haben sich so etwas ähnliches dabei gedacht, also sie die kombinierten Try-Catch-Finally-Blocke ins Sprachkonzept aufgenommen haben. Das sie bei Delphi fehlen, ist schade, aber es gibt Schlimmeres.