nikosch

Obwohl meine letzte Sessiondesignfrage nicht wirklich zielführend war, möchte ich trotzdem noch einmal eine Allgemeinfrage stellen. Ich weiß, jede Applikation ist anders, aber:

Wie baut Ihr Eure Exception-Systematik auf? Kennt Ihr Konzepte und Quellen, die diese näher beschreiben?


Ein wesentlicher Vorteil von Exceptions ist ja, dass sie im Extremfall vom Auslösepunkt bis zur Applikationswurzel hindurchfallen. Wenn man sich jetzt eine Applikation aus einer Menge von Seiten, diese wiederum aus einer Menge von Modulen*) und selbige aus einer Menge von Funktionen/Methoden vorstellt, tut sich mir die Überlegung auf, wann und wo ich welche Ausnahmen behandle.
Man könnte jetzt in traditioneller or die()-Mentalität den User mit einer Plaintext-Meldung beglücken. Es gäbe jedoch auch andere Möglichkeiten:

- das auslösende Modul zeigt statt seines Inhalts eine Fehlermeldung an
- das auslösende Modul wird nicht angezeigt
- das auslösende Modul triggert das Haupt-Content-Modul an, eine Fehlermeldung anzuzeigen
- das auslösende Modul triggert die Seite an, das Haupt-Content-Modul auf einen neuen Inhalt zu setzen
- das auslösende Modul triggert die Seite an, die Modulstruktur komplett zu verwerfen und ein statisches Fehlerdokument anzuzeigen
- das auslösende Modul triggert die Applikation an, selbiges zu tun
- das auslösende Modul triggert die Applikation an, einen 404 Header oder eine Umleitung auf das Errordokument abzusetzen


Diese Möglichkeiten kann man jetzt im Kontext des auftretenden Fehlers

- temporärer DB Fehler, Timeout
- permanenter Fehler (Ressource fehlt, falsche Ordnerrechte, fehlende PHP Library...)
- Modul fehlt, Programmfehler, "logische Exception"
- Datenbankverbindungsfehler (betrifft dann auch andere Teile der Anwendung)
- Fehler in Verbindung mit Parameterdaten, fehlgeschlagene Validierung
...

und der Auswirkungen auf die Applikation

- Modul ist nicht relevant für die Funktionalität der Anwendung (Feedreaderbox o.ä.)
- Fehler-Aktion ist nicht relevant für die Funktionalität (Caching eines Inhalts o.ä.)
- Modul ist tw. relevant für die Funktionalität der Anwendung (Warenkorbanzeige)
- Modul besitzt hohe Priorität (Authentifizierung)
...

sehen.

Manche Anwendungsfälle mögen auch eher durch Fehler als durch Exceptions abgedeckt sein.

Welche Fehlerstadien (aus Usersicht) richtet Ihr ein, wo lasst Ihr welche Exceptions verarbeiten? Bin gespannt auf Eure Gedanken


*) Als Module bezeichne ich hier eigenständige Programmkomponenten (meist mit Viewkomponente), die untereinander verschachtelt die Funktionalität und Ausgabe der Applikation ausmachen.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mister Ad

phpdummi

Noch nicht gehört, aber bestimmt interessant: The ZendCon Sessions Episode 24: Elegant Ways of Handling PHP Errors and Exceptions

Ansonsten bin ich mal gespannt was die anderen so schreiben!

EDIT: Die MP3-Version hat eine gute Qualität, wesentlich besser als in diesem JW-Player.

__________________
"Nobody is as smart as everybody" - Kevin Kelly
— The best things in life aren't things

Chriz

Von der Theorie her würde ich grundsätzlich Exceptions an folgende koppeln:

PHP: Exceptions - Manual
LogicExceptions also für harte Anwender-unabhängige Fehler (DB down, Konfig nicht gefunden, ..) und auch glatt abspringen, sprich erst in der index.php fangen.

RuntimeExceptions würde ich noch einmal jeweils mit Code markieren (2. Konstruktor-Parameter), USER, GENERAL, .. So kannst du auch RuntimeExceptions entschärfen in der Ausgabe (manchmal sind Details gut, manchmal nicht). Übrigens kannst du seit PHP 5.3 einen Exception-Stack aufbauen:
PHP: Exception::__construct - Manual
Wie man Exceptions letztlich auflöst finde ich sehr Problem abhängig, da kann man so pauschal ja wirklich nur sagen: der, der noch so Kontext nah ist, um das Problem zu verstehen, zu lösen oder entsprechend an den eigenen "Boss" (try-Block) die Meldung zu machen und auch nur der entscheidet, wie schwerwiegend das Problem ist. Kann ja sonst sein, dass ein News-Skript die news.txt nicht findet, in Panik verfällt und gleich den Supergau ausruft, das Ding aber letztlich nur als kleiner Ticker in der Seitenleiste auftauchen soll (wie dus auch schon oben gesagt hast). Der gleiche Code könnte ja aber auch beim Aufruf der "Vollbild"-Newsseite passieren, da könnte man die Seite dann ja durchaus abbrechen. Sprich selber Fehler, andere Behandlung. Also von oben herab bestimmen was passiert, nicht umgekehrt.

try-catch soll ja recht langsam sein, aber wenn man Ausnahmebehandlung ernst nimmt, sollte eigentlich jeder Fremdaufruf bzw. Hierarchie (einzeln oder Blockweise) in einen try-catch-Block (sofern die Fremdklasse überhaupt Exceptions wirft).

__________________
"Nuschel ich?" - "Was?"

Peterle

Ich schicke jeden Fehler der auf meiner Seite ensteht mir per E-Mail zu und logge diesen zusätzlich in einer Datei.
Der User bekommt eine höfliche "Ups"-Meldung (*g*) und von Variablen, Funktionen etc. bekommt der User nichts zu sehen.
Die E-Mail beinhaltet nicht nur Fehler-Typ, Fehler-Meldung, Zeile, Datei, User-IP, Request-Methode, Query String und Referrer, sondern auch jeweils +/- 5 Zeilen Code um den Fehler.

nikosch

Ja schon klar, darum gehts aber hier nicht wirklich. Und Ups-Meldungen sind nicht das was ich anstrebe. Etwas flexibler darf das Konzept schon sein.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

dr.e.

Hallo nikosch,

Wie du schon erkannt hast, ist diese Frage nicht so einfach mit einem Satz zu beantworten. Grundsätzlich gilt jedoch das einfache Prinzip, dass jede Exception auch gefangen werden muss. Die Art und Weise des Fangens kann dabei unterschiedlich sein: "lokale" Exceptions einer Anwendung sollten auch dort gefangen und behandelt werden, "lokal" nicht verarbeitbare Exceptions sollten in den globalen Fokus gelangen und dort mit einer zentralen Behandlungs-Routine belegt werden.

Was die Auswirkung von Exceptions angeht, gibt es auch unterschiedliche Konzepte. "Kleine, spezialisierte" Exceptions dürfen dabei nie zu einem groben Fehlverhalten der Gesamt-Applikation führen, "große" Exceptions jedoch schon. Zu letzterem zählen vor allem Probleme, die ein Ausführen der Applikation nicht mehr möglich machen.

Lokale Exceptions, die auf jeden Fall gefangen und behandelt werden können:
Globale Exceptions, die global gefangen und behandelt werden müssen:
Für letztere kannst du z.B. eine allgemeine Fehlerseite anzeigen, oder den Fehler fangen und (sofern möglich) auf die Startseite oder eine Seite ohne DB-Anteil weiterleiten.

Was das globale Handling von Exceptions angeht, so könntest du personalisierte Fehlerseiten bauen, in dem du konfigurierst, bei welcher Exception welche "schöne" Fehlermeldung angezeigt werden soll. Treffen alle konfigurierten Fälle nicht zu, gibt es eine allgemein Meldung.

Ich hoffe, das hilft dir etwas weiter.

Viele Grüße,
Dr.E.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mepeisen

Pauschal gilt das natürlich schon, wobei man aber ergänzen sollte, dass es durchaus praktikabel sein kann, schwere Anwendungsfehler durch ein allgemeines "catch (Exception)" an deinem äußersten Application-Rahmen zu fangen. Und da hilft dann auch die grobe Einteilung, die PHP selbst vorgibt (siehe Post von Chriz).
In jedem einzelnen Anwendungsmodul beispielsweise sinnvoll auf eine Exception zu reagieren, nur weil sie die aufgerufene Methode wirft, ist manchmal einfach unsinnig, denn der Aufrufer hat eine Selbstverantwortung, zu entscheiden ob eine Exception nun bedeutet, dass der Aufrufer mit anderen Programmteilen weitermachen kann oder ob sie bedeutet, dass sie zu einem irreparablen Zustand führen soll. Sprich: Entwickelt man völlig modular, ergibt sich die Schwere des Problems ergibt sich nicht immer zwangsläufig aus der Exception selbst.
Und wenn man sich an diese Vorgabe hält, für ganz besondere Umstände im äußern Rahmen eine Art "Fallback" einzubauen, werden alle bis dato nicht gefangenen Exceptions als schwere Anwendungsfehler angesehen, was so zumindest erst einmal nichts völlig verkehrtes ist.

generell gilt es aber, wie hier angeklungen ist, selbst zu verstehen, was man mit einer Exception erreichen will. Generell ist eine Exception wertneutral eine Exception (=Ausnahme zu deutsch). Also eine Ausnahme im Programmablauf.
Exceptions können logisch gesehen folgendes sein:
- Irreparable Programmzustände (DB-Connect fehlerhaft usw.)
- Logische Fehler, die der Aufrufer fängt und zur Kenntnis nimmt um seinerseits eine alternative Verarbeitung zu machen (zum Beispiel Exceptions zum Anzeigen einer fehlgeschlagenen Validierung, was jedoch den weiteren Programmablauf nicht massiv stört)
- Logische Fehler, die vom Aufrufer provoziert werden.
Exceptions werden sogar manches mal als eine Art Informationsträger genutzt, sind also nicht zwangsläufig gleichbedeutend mit einem Fehler.

Bevor ich also soweit gehe, um mir um die Fehlerbehandlung als solches Gedanken zu machen, versuche ich immer erst, mir Gedanken zu machen, was meine Exception eigentlich bewirken soll und in welche Kategorie sie passt.
Manches mal ergibt sich die Behandlung auch erst aus dem Kontext. Wo man bei der normalen Anwendung im Normalfall die Datenbankfehler bis oben hin durchreichen lässt um dann eine allgemeine Fehlerseite o.ä. einzublenden, so nimmt man beispielsweise während der Installation einen fehlgeschlagenen DB-Connect auf andere Art und weise zur Kenntnis.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

dr.e.

->

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mepeisen

Ich hab mich ebbes blöd ausgedrückt. Wie dem auch sei, ich wollte mit meiner langen Rede eigentlich vor allem darauf hinaus, dass der Aufrufer selbst meist erst über die Schwere des Fehlers entscheidet. Manches mal sind die gleichen Fehler so schwerwiegend, dass sie vom Aufrufer nicht mehr sinnvoll verarbeitet werden können, manches mal sind sie eine Information für den Aufrufer.
Der DB-Connect ist in Zusammenhang mit dem Unterschied zwischen dem Aufrufer während dem Betrieb und dem Aufrufer während der Installation ein von mir gerne genommenes Beispiel. Obwohl vom gleichen Modul eine ConnectionFailedException generiert werden kann, mag der eine Aufrufer diese als fatale Exception sehen und kann keine sinnvolle Webseite anzeigen. Im Zweifel wird auch nicht geschaut, was genau falsch ist, denn diese Detailinfo hat den Besucher der Seite nicht zu interessieren. Die Installationsroutine jedoch gibt dem Benutzer das reguläre Formular aus und weist ihn darauf hin, dass seine Informationen wohl nicht korrekt waren. Zudem ist für die Installationsroutine durchaus interessant, ob der Connect nicht klappte oder das Passwort falsch war oder die DB nicht existierte...

Bei dir hatte ich das etwa so verstanden, dass du der Meinung bist, man sollte gewisse Exceptions eigentlich immer sinnvoll weiterverarbeiten können. Das mag auch in 95% der Fälle stimmen aber ebend in 5% der Fälle nicht.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

dr.e.

Wir verstehen uns also prächtig! Freut mich.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~