Wann wirft man eine Exception

[Der-Dennis]

Hey dedlfix,

Ich kann da nur von mir ausgehen: Für mich ist jede Exception erstmal mit einem Programmabbruch verbunden, da irgendetwas gewaltig schief gelaufen ist (wie z.B. eine nicht vorhandene Datenbank-Tabelle, wobei natürlich alles auf den speziellen Anwendungsfall ankommt).

Das ist meiner Meinung nach noch nicht so gewaltig, komplett abzubrechen. In dem Fall wird man üblicherweise zwar die geplante Aktion abbrechen, man kann jedoch einen alternativen Weg gehen.

Wahrscheinlich sind meine "fatalen Fehler" tatsächlich nicht so fatal, wie ich annahm...

In dem sollte man irgendwas sinnvolles für den Anwender ausführen, zum Beispiel seine Bestellung per Mail abschicken, anstatt ihn in die Arme der Konkurrenz zu entlassen,

Das bedingt aber, dass ich das Fehlschlagen im Produktivbetrieb bereits eingeplant habe. Wie bereits gesagt gehe ich aber davon aus, dass die (meisten) Exceptions im Produktiveinsatz nicht geworfen werden sollten, da ich (hoffentlich) alle Fehlerquellen für diese Exceptions schon eliminiert habe. Was Du beschreibst trifft aber auf meine "speziellen Exceptions" zu.

oder ihm sagen, was er zur Zielerreichung machen kann.

Damit habe ich persönlich schlechte Erfahrungen gemacht. Viele Benutzer halten eine "sinnlose", automatische Fehlermeldung für besser als eine Fehlermeldung, die ihnen Alternativen aufzeigt. Bei der Fehlermeldung mit dem Angebot von Alternativen denken viele: "Aha. Die kennen das bereits. Aber anstatt was dran zu ändern (sind die zu blöd dazu?), wollen die jetzt, dass ich mich damit zufriedengebe und die Arbeit für die übernehme." Bei der nicht-aussagekräftigen: "Mal wieder diese sch***-Computer. Immer das gleiche. Naja, dann versuche ich es halt nochmal."
Traurig, aber wahr: Bei einer aktuellen Studie in unserem Institut kam genau das raus.

Gewaltige Ereignisse wäre eher sowas wie Speicherüberlauf, und das meldet PHP herkömmlich und unabfangbar.

Ok, stimmt! Wir müssen unterscheiden, ob es sich um Exceptions handelt, auf die ich im Programmfluss reagieren KÖNNTE und solchen, bei denen im Augenblick "Hopfen und Malz verloren sind".

Anders ist es bei Exceptions, mit deren Auftreten ich rechne: Die bekommen einen eigenen try-Block mit einem spezifischen catch. Häufig nutze ich das z.B., wenn ich damit rechne, dass eine Datei nicht vorhanden, dies aber für den weiteren Programmfluss irrelevant ist.

Es kommt drauf an, ob ich in dem Falle eine Exception erzeugen würde. Ist die Datei normalerweise vorhanden, dann ist es eine Ausnahme, wenn sie weg ist (z.B. Konfigurationswertedatei im Normalbetrieb). Für ein Setup-Script, das die Datei erstellen oder wenn vorhanden ändern soll, ist es Normalfall, wenn die Datei nicht existiert und rechtfertigt im Prinzip keine Exception.

Da muss ich mal drüber nachdenken. Im Grunde hast Du aber sicherlich recht. Wo wir ja wieder bei T-Rex Ausgangsfrage wären...

In der Regel wird man sogar nicht mal wissen, wie weit Aufgabe und Ausgabe gediehen sind, um sie einigermaßen ordentlich abzuschließen.
Meiner Meinung nach sollte die Ausgabe erst ganz zuletzt ausgeführt werden, sodass das kein Problem darstellen sollte (außer natürlich, BEI der Ausgabe tritt eine Exception auf; hm, wo ich da gerade so drüber nachdenke: Was macht man in so einem Fall?).

Dann wird man vielleicht ein bereits gerendertes Seiten-Gerüst haben, in das man statt der seitenspezifischen Ausgabe eine Alternative einfügt. Oder man hat gar nichts, und muss sich halt was angemessenes für den Fall ausdenken.

Das schon. Aber was, wenn irgendwo dabei ein Fehler auftritt? In letzter Konsequenz darf ich bei sowas doch keine Exception mehr werfen, sondern muss mich auf das interne Error-Handling verlassen!? Sonst käme man doch in Endlosschleife: Anwendungs-Fehler => Exception => Error-Seiten-Fehler => Exception => Error-Seiten-Fehler => Exception... Oder habe ich da was nicht bedacht?

Die Aufgaben abzuschließen ist in diesem Fall doch auch kein Problem? Im Gegensatz zu fatalen Fehlern werden doch bei Exceptions die Destruktoren der Klassen noch ausgeführt oder irre ich mich?

Das weiß ich auch grad nicht. Aber ein Destruktor wird die Aufgabe nicht abschließen können, sondern nur die geöffneten Ressourcen ordentlich schließen können. Aber ...

Hab's grad getestet, die Destruktoren werden aufgerufen. Was aber natürlich nichts daran ändert, dass...

So könnte man beispielsweise bei den Datenbank-Aufgaben doch einen Roll-Back für alles Unvollständige durchführen (wie gesagt, bin mir nicht sicher und korrigiert mich bitte, wenn dies falsch ist).

... bei Datenbankaktionen muss man immer mit einem Fehlschlagen rechnen, weswegen die in einen eigenen try-Block gehören. Und dann kann man in den catch-Teil das Rollback einfügen und allgemeine Abschlussarbeiten für Gut- und Fehlerfall ins finally.

ich mir bei einigen Dingen nochmal Gedanken über die Grund-Designs machen muss...

Auch wenn's eigentlich T-Rex Thread ist, kann ich Dir wieder nur für Deine Anregungen danken!

Gruß,
der T-Rex mag mein "Gruß," nicht
Dennis