Exception ansich sind ein sehr wichtiges Mittel der Programmierung geworden. Sie stellen sozusagen einen parallel zum eigentliche Programablauf feststehenden Programmablaufplan dar. Und exakt in dieser Parallelität sehe ich auch gleichzeitig die Schwäche der Exceptions. Denn im Denkvermögen der meisten Programmierer stellt sich ein Program am einfachsten als simple und rein sequientielle Steuerung dar.
Exception widersprechen also unserem Denkvermögen, meistens zumindestens. Nun, das bedeutet das asynchron eintreffende Exceptions oder auch Events immer eine Denk-Hürde für die meisten Programmierer darstellen, ergo potentielle Fehlerquellen. Das schlimme daran ist es das diese Fehlerursachen meistens noch viel stärker Nachfolgefehler nach sich ziehen.
Meine Lösung aus diesem Dilema lauten:
1.) wenn
Exception dann aber auch immer try finally benutzen um resourcen zu schützen, das verringert die Anzahl unerwünschter Nachfolgefehler falls eine
Exception/Event asynchron den Programfluß unterbricht.
2.) Wissen, die Programmierer habe zu lernen wie asynchrone Programme per Exceptions/Events zu arbeiten haben
3.) Beschränkungen, durch willkürlich Beschränkungen auf gemeinsam benutzte und Firmeninterene Vorgaben im Arbeitsstil.
4.) das Eintreffen/Auslösen solche asynchrone Exceptions/Events möglichst reduzieren. Besonders eben in
RTL/Helper Funktionen sollte man auf Exceptions verzichten und stattdessen über Rückgabewerte einen Fehler signalisieren. Nichts ist schlimmer wenn eine solche Funktion tief im Inneren eines Programmes ständig Exceptions auslösst. Das führt dann dazu das der Programmierer wie wild alle möglichen
Exception abfängt und somit den Nutzeffekt solcher Exceptions auf Null reduziert. Denn eine
Exception macht meistens nur dann Sinn wenn sie auch sichtbar wird und somit die Ausnahme auch ersichtlich ist.
Gruß hagen
Zitat
Baum-Darstellung
