nicht angemeldet
Hi,
Exceptions sind nicht dazu da, Geschäftslogik zu bauen
Fakt ist jedoch: Zur Fehlerbehandlung in Perl-DBI wird RaiseError nach wie vor empfohlen und genau das läuft auf eine Exception.
bleiben wir mal bei diesem Beispiel.
Wann treten denn mal Datenbank-Fehler auf:
(a) Statement ist fehlerhaft.
Sollte nur während der Entwicklung auftreten. Ich habe aber auch noch nie Geschäftslogik gesehen, die Bugs behandelt (vielleicht sollte ich hier eher "selten" denn "nie" sagen :))
(b) Datenbank ist nicht erreichbar.
Das ist sicherlich kein normaler Geschäftsfall. Muss (klar) abgefangen werden, aber Geschäftslogik ist das nicht.
(c) Es wird "auf Verdacht" etwas in die Datenbank geschrieben, wo mit einem Fehler gerechnet wird. Beispielsweise wird einfach versucht, etwas in eine Spalte einzufügen, wo dann etwa ein UNIQUE-Constraint fehlschlägt. Dies wäre Geschäftslogik, aber der Fall wird dann immer lokal behandelt und die Exception eher selten groß durch die Applikation gejagt.
Insofern ist der Regelfall Fall (b) und Exceptions für (c) zu nutzen ist eher ein "Abfallprodukt", da man dort i.d.R. nur braucht, dass es fehlgeschlagen ist.
Fallen dir mehr Fälle ein?
Bis die Tage,
Matti