Wann wirft man eine Exception

[dedlfix]

Tach!

Sooooo nehmen wir mal an der Tabellenname wird im Konstructor übergeben. Dann kann es natürlich sein, dass man einen Tabellennamen übergeben könnte, den es schlicht nicht gibt. Dann wäre natürlich eine Funktionalität nicht schlecht, welche überprüft ob es den Tabellennamen gibt oder nicht. Wenn es den Tabellennamen nicht gibt sollte logischerweise eine Exception geworfen werden. Bei diesem Beispiel sehe auch ich auf anhieb das eine Exeption an der Stelle fast schon zwingend ist.

Angenommen, du hast dich dafür entschieden, den Tabellennamen im Konstruktor (oder vom Konstruktor initiiert) zu prüfen, dann wäre eine Exception (wenn ich jetzt nichts übersehen habe) die einzige Möglichkeit, eine Instantiierung des Objektes zu verhindern. Anderenfalls wird ein Objekt erzeugt, und wenn du nicht irgendeine Eigenschaft oder Methodenrückgabewert prüfst, die/der dir Prüfungsfehler signalisiert, bekommst du höchstwahrscheinlich Folgefehler.

Den Tabellennamen zu prüfen ist technisch kein direktes Problem. Du kannst zum Beispiel das INFORMATION_SCHEMA befragen. Dazu wird aber jetzt schon eine Datenbankverbindung benötigt und Dinge wie Lazy Connect wären damit schon gestorben. Eine Alternative wäre, nur offensichtliche Problemfälle zu prüfen (Leerstring) und den Rest der sowieso benötigten Reaktion auf andere syntaktische Fehler zu überlassen.

Dann stehe ich aber vor dem unschönen Problem dass ich jedes erzeugen einer Instanz mit einem Try/Catch umschliessen muss. Wenn ich das richtig sehe, kann ich meinen alten Chef verstehen, der sich komplett gegen Exceptions ausgesprochen hat. Das würde den Code unnötig aufblähen.

Der Code "bläht" sich mit jeder Art, auf un- und vorhersehbare Fehler zu reagieren, auf. Wenn du kein Exception-Handling nimmst, brauchst du für ein robustes Programm eben "herkömmliche" if-else-Unterscheidungen. Diese jedoch stehen an jeder Stelle, an der was passieren kann. In einem try-Block hast du wenigstens die Möglichkeit, ein Bündel voll Anweisungen zu notieren, und dabei erstmal vom Gut-Fall auszugehen, ungestört durcharbeiten zu können. Besonders dann ist das interessant, wenn dich nicht der genaue Fehlerort interessiert, sondern nur ob während dieses Bündels alles gut ging oder eben nicht. Als Programmierer wirst du dich vielleicht für die genaue Stelle interessieren, der Anwender, der statt der Anweisungen des Bündels jedoch nur eine Einzelaktion (in seinem UI) sieht oder startet, kann mit einem solchen Detail weniger anfangen und bekommt nur das Ergebnis zu sehen. Damit der Programmierer nachher in seinen Logs oder aus der vorgelesenen Fehlermeldung die genaue Stelle findet, ist eine Unterscheidung wichtig. Das kann einerseits ein signifikanter Meldungstext sein, andererseits auch bereits durch den Namen der Exception eindeutig werden. Und damit hätten wir dann auch einen Grund, eigene Exceptions abzuleiten. Die müssen ja nicht unbedingt Funktionalität zur Basis-Exception hinzufügen, ein anderer Name reicht oftmals schon für die Erkennbarkeit der problematischen Stelle.

Ein weiterer Grund für die Erstellung eigener Exceptions ist, dass man zum Beispiel Datenbankfehler erwartet und in seinem Catch-Block nur darauf reagieren will. Für andere Exceptions hat man für den Augenblick keine Reaktion vorgesehen, also lässt man die anderen ungefangen weiterziehen und kümmert sich vielleicht in irgendeiner übergeordneten Ebene darum.

dedlfix.