Verwendet ihr immer Try - Catch bei Datenbank Abfragen??

[hawkmaster]

Hallo zusammen,
mich würde einfach mal interessieren wie es ihr mit Try- Catch handhabt.

Ich muss gestehen das ich es bisher nur sehr sparsam eingesetzt hatte.
Eher sowas wie;
$result = mysql_query("SELECT UserID FROM usertabelle WHERE username= '{$username}' ") or error(__LINE__,__FILE__,"Could not search database for this user",mysql_error());

Setzt ihr es grundsätzlich ein, auch bei einfachen Selects oder nur bei Abfragen, Inserts, Updates und Deletes die aufwendiger sind?

vielen Dank und viele Grüße
hawk

[Vinzenz Mai]

Hallo,

mich würde einfach mal interessieren wie es ihr mit Try- Catch handhabt.
Setzt ihr es grundsätzlich ein, auch bei einfachen Selects oder nur bei Abfragen, Inserts, Updates und Deletes die aufwendiger sind?

seit diesem Posting hab' ich meine Einstellung noch nicht geändert.

Freundliche Grüße

Vinzenz

[Thorsten]

Hallo,

zum debuggen eines Skriptes sollten immer alle Fehler ausgegeben werden, auch wenn dieses nur Notizen sind.
Das gilt auch für MYSQL Fehler.

Wenn das Projekt fertig ist und in den Einsatz geht. Müssen zwingend alle Fehlermeldungen aus Sicherheitsgründen abgeschaltet werden. MSQL Fehler schreibe ich z.b. in einer Textdatei die ich als Admin dann auswerte.

Aber MYSQL Fehler im Live betrieb auszugeben, gibt dem event. möglichen angreifer die Möglichkeit die Datenbankstrukture nachzuvollziehen.

So sind SQL Injektionen für den Angreifer einfacher.

Daher immer Fehlermeldungen Protokolieren und nicht ausgeben.

[Sven Rautenberg]

Moin!

Setzt ihr es grundsätzlich ein, auch bei einfachen Selects oder nur bei Abfragen, Inserts, Updates und Deletes die aufwendiger sind?

Mit der Aufwendigkeit hat das nichts zu tun, sondern mit der grundsätzlichen Herangehensweise an die Fehlerbehandlung.

Ich persönlich halte das Werfen von Fehlern für nicht sonderlich schön, da es dazu verführt, sich nicht konkret an der jeweiligen Programmstelle mit den denkbaren Fehlerkonditionen auseinanderzusetzen, sondern sich "später" und "allgemeiner" damit zu befassen. Das führt dann am Ende zu so netten und informativen Dialogboxen wie "unerwarteter Fehler 23".

- Sven Rautenberg

[Jurik]

Seit dem ich mit der PDO Klasse arbeite und eine ERROR-Klasse einsetze (einerseits um den Fehler intern weiter zu verarbeiten und nach außen eine verständliche Fehlermeldung anzuzeigen) komme ich um Try & Catch nicht herum und bin sehr zufrieden.

(OffTopic: Besonders gut ist es auch bei einer selbstgeschriebenen getElementsByClass Function ;) )

[Daniel Thoma]

Hallo hawkmaster,

ich programmiere kein PHP und kann nicht sagen, wie brauchbar Exceptionhandling dort umgesetzt ist. Ich halte generell allerdings nichts davon, Fehler- oder Ausnahmesituationen im regulären Programmablauf zu behandeln und diesen damit komplexer zu machen. Das sollte komplett über Exceptions laufen.

Eine sinnvolle Methode, Exceptions an höhere Ebenen weiter zu reichen, ohne dort dann mit einer Vielzahl von "technischen" Exceptions arbeiten zu müssen, ist Exception Chaining.

Man fängt also jede Exception, die auftreten kann und wenn diese lokal nicht sinnvoll verarbeitbar ist, wirft man sie nicht einfach weiter, sondern wirft eine neue, anwendungsspezifische Exception, die auf die ursprüngliche verweist.

So könnte man generell eine ApplicationException haben, die auf oberster ebene abgefangen wird und zur Ausgabe einer "benutzerfreundlichen" Fehlermeldung führt. Wenn im DB-Subsystem dann z.B. eine DBException auftritt, macht man etwa so etwas:

try {

} catch (DBException e) {
  throw new ApplicationError(DB_ERROR, DBException);
}

Dieses Muster ermöglicht, von konkreten Exceptions zu abstrahieren und in höhreren Anwendungsebenen, wo man den konkreten Fehler sowieso nicht mehr behandeln kann, nur noch damit umgehen zu müssen, dass in einem Subsystem ein Fehler aufgetreten ist, was man dort entsprechend bearbeiten kann (doch deaktivieren des Subsystems, erzeugen einer Fehlermeldung, etc).

Zusammenfassend: Man muss sich etwas überlegen, wie man Exceptionhandling vernünftig einsetzt, aber meines Erachtens gibt es keine robustere Methode, mit Fehlern umzugehen. Returncodes haben eigentlich nur Nachteile. Man hat aus gutem Grund Exceptions erfunden ;)

Grüße

Daniel