Grundsatzdiskussion über Exceptions

[Parantatatam]

Hallo Tutorianer!

Ich stehe gerade mal wieder vor einer meiner Lieblingsgrundsatzmonologe: sollte man Exceptions quasi überall nutzen oder reicht auch manchmal nur ein return false oder sollte man sogar versuchen die Daten versuchen so gut wie möglich zu verwerten?

Um es mal an einem praktischen Beispiel zu verdeutlichen: ich bastle gerade mal wieder etwas an dem ActiveRecord-Entwurfsmuster und da gibt es sogenannte Finder, also Selektoren. Man kann unteranderem komplette WHERE-Klauseln angeben, aber auch einzelne IDs oder WHERE-Klauseln auf Basis von Arrays oder folgende Selektoren: first, last, all.
Wenn nun aber der Nutzer aus irgendwelchen Gründen einmal first und einmal all in der gleichen Abfrage verwendet, sollte ich dem Nutzer dann lieber false ausgeben, seine zweite Angabe ignorieren oder ihm doch gleich eine InvalidArgument-Exception raushauen? Wie löst ihr das? Bin ich vielleicht einfach zu zögerlich, was den Einsatz von Exceptions betrifft? Weil letztendlich wäre es für mich einfacher, wenn ich an so einem Punkt einfach abbrechen würde (Exception). Außerdem würde das auch die Performance steigern, wenn ich nicht jedes Deppen Fehler ausbessere.

 

[saftmeister]

Ich setze Exceptions vor allem dort ein, wo ein Handling nötig ist, was den weiteren Stack unterbricht. Auf false oder null zu Prüfen kann bei umfangreichen Aktionen schon mal die Hölle werden. Sobald Klassen Einzug halten sind Exceptions das Mittel der Wahl. Dann kann auch nicht vergessen werden im weiteren Verlauf die Rückgabewerte zu prüfen. Exceptions sind also auch etwas zusätzliche Sicherheit.

Ich setze eigentlich ausschließlich Exceptions ein da:

- der normale Ablauf nicht durch eine Exception betroffen wäre
- der ausnahmenbehaftete Ablauf durchaus ein Grund sein kann, inkl. Call-Stack zu tracen
- man einfach mal einen Datenbank-Rollback dadurch auslösen kann (sicher, geht auch mit false oder null, aber so hab ich schön zentral eine Stelle, an der das Rollback erledigt werden muss)

Ich finde es nur schade, das es bei PHP kein so ausgeklügeltes Transaktionshandling gibt wie bei Java, bei der eine Transaktion auch einfach mal zurück gerollt wird inkl. aller Statements, die auf die Datenquelle innerhalb des Session-Kontextes ausgeführt wurden.

 

[Parantatatam]

Magst du mir das Letzte noch einmal genauer erklären? Ich komme nämlich gerade nicht dahinter, warum das in PHP nicht geht oder sehr schwierig sein sollte. Mit der PDO beispielsweise kann man doch Abfragen sehr leicht zurück rollen. Und wenn man sich nur etwas bemüht, dann kann man doch letztendlich alle Daten zurücksetzen.

 

[saftmeister]

In Java wird die Transaktion implizit zurück gerollt, wenn innerhalb des Transaktionskontexts eine Exception auftritt. Bei PHP muss man das explizit tun. Klar, ist kein Problem, aber wenn man es vergisst ;-)

 

[Parantatatam]

Dann sollte man vielleicht eine eigene BasicException definieren, welche alle Datenbankverbindungen kennt, und dann beim Initieren erkennt, ob sie innerhalb eines Transaktionskontextes liegt. Das muss doch irgendwie gehen.

Aber ansonsten schon mal danke für deine Aussagen zu den Exceptions. Es hat mich nur in meiner Annahme gestärkt und ich werde jetzt versuchen Exceptions quasi überall zu verwenden und dem Programmierer nach mir damit auf die Finder hauen, dass er doch ordentliche Parameter übergeben soll.