nicht angemeldet
Tach!
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. 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, oder ihm sagen, was er zur Zielerreichung machen kann. Gewaltige Ereignisse wäre eher sowas wie Speicherüberlauf, und das meldet PHP herkömmlich und unabfangbar.
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.
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.
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 ...
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.
dedlfix.
Der Martin