Hi Topeg,

danke Dir!

Quote

Es ist zwar nett alles in eval zu packen, aber hier ist es unnötig, da DBI sauber arbeitet und kein die macht wenn man es nicht wünscht.

Es gibt _immer_ mehrere Möglichkeiten und $dbi->errstr greift auch auf eine globale Veriable. $dbi->errstr funktioniert überdies nur, wenn das Handle erstellt werden konnte.

Von daher leitet sich die Empfehlung ab, RaiseError bereits beim connect zu setzen, da es die Einzige Möglichkeit ist, zu erfahren, warum der connect schief geht. Das hat dann eben zur Konsequenz, dass jeder Fehler eine Exception wirft, es sei denn, RaiseError wird nach dem connect wieder auf Null gesetzt (wäre zu prüfen).

Dein Tipp mit der eigenen Fehlerfunktion ist auf jeden Fall eine feine Sache und empfehlenswert, die meisten meiner Module haben eine Solche. In meinem Artikel

http://rolfrost.de/map/article/cgi/fin

habe ich beschrieben, was mit einer eigenen Fehlerfunktion möglich ist.

--Rosti

Edit: Artikel ergänzt um einen Abschnitt "Fehlerbehandlung" mit oder ohne RaiseError. Ich persönlich werde $@ weiterhin bevorzugen, das wird im Gegensatz zu $DBI::errstr NICHT überschrieben, sofern auch nur eines der im eval{}-Block notierten Statements fehlschlägt.

Wenn RaiseError gesetzt ist, werden die im eval-Block abgesetzten Statements erst wirksam in der DB, wenn _alle_ Statements korrekt sind. Ergo: Mögliche Fehler sind gut aufzuspüren, zügige Arbeitsweise ;)
Last edited: 2011-08-01 11:42:53 +0200 (CEST)