nicht angemeldet
Hey dedlfix,
Das kommt drauf an, wie man "ausreichend" definiert. Eine ungefangene Exception bedeutet immer Programmabbruch. Das dürfte aus Anwendersicht eher "ungenügend" sein.
das stimmt natürlich, aus Anwendersicht taugt das gar nichts. Aber deshalb sollte das Programm ja auch möglichst so ausgereift sein, dass keine kritischen Exceptions geworfen werden müssen.
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).
Da ich set_exception_handler() (in PHP) verwende, kann ich jetzt erstmal an allen möglichen Stellen mit Exceptions um mich werfen (nein, so schlimm ist das in der Praxis natürlich nicht), die ja alle gefangen werden. Das Programm sollte dann so sein, dass diese Exceptions im Produktivbetrieb erst gar nicht mehr geworfen werden müssen, sonst hab ich einen großen Fehler im Programm eingebaut oder es ist etwas wirklich schwerwiegendes passiert; dann ist ein Abbruch aber auch gerechtfertigt.
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.
Daher also meine Aussage "häufig ausreichend", da es bei mir sehr viele kritische Exceptions, jedoch nur wenige spezielle gibt.
Den Gedanken hatte ich auch schon. Das setzt aber voraus, dass der gesamte Code in einen try passt. Wenn man irgendwas nochmal zusätzlich kapseln möchte funktioniert es schon wieder nicht. Dann hätte man pro Kapselung nochmal einen try.
Bei der Funktion habe ich mir noch keine Meinung gebildet. Die kannte ich aber in der Tat nicht - danke!Die ist auch eher als allerletzter Notnagel zu verstehen, ähnlich wie set_error_handler() für herkömmliche Fehler. Allerdings stoppt die Ausführung des Scripts nicht nach dem Ausführen des Errorhandler (bei weniger schwerwiegenden Meldungsklassen). Auf auftretende Fehler sollte man, soweit möglich, vor Ort reagieren und einen möglichen alternativen Programmzweig ausführen, der allen Seiten etwas bringt. Der oberste Fehlerhandler kann nicht viel mehr als das Auftreten für den Administrator dokumentieren und eine allgemeine Tröstmeldung an den Anwender geben.
Das stimmt natürlich alles!
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?).
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? 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).
Gruß, Dennis
Der Martin