nicht angemeldet
Tach!
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.
Du kannst bestimmte Situationen vorhersehen und sie trotzdem nicht beeinflussen. Syntaxfehler im Statement kann man vermeiden. Dass ein DBMS jedoch grad mal Pause macht, lässt sich nicht eliminieren. Du kannst lediglich mit entsprechendem Aufwand für eine höhere Verfügbarkeit sorgen, aber 100% wirst du nicht erreichen können. Das gleiche gilt für alle anderen externen Dienste, die man anzusprechen gedenkt.
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?
Das sollte dann so einfach sein, dass es keinen Fehler mehr produzieren kann, beispielsweise eine fest codierte Mini-HTML-Seite. Noch etwas variablen Text einzufügen ist auch exceptionlos möglich.
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?
Theoretisch schon, aber wir befinden uns in einem globalen Exception-Handler, der sollte nicht auch noch Exceptions werfen um die maximale Rekursionstiefe des Systems zu testen ...
... 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.
finally kennt PHP nicht, hab ich grad beim Recherchieren für meine andere Antwort festgestellt.
dedlfix.
Der Martin