nicht angemeldet
Hi,
Die Frage war, in welchen Fällen Exceptions durch die Datenbank geworfen werden.
Exceptions wirft der Layer, nicht die DB
Entschuldige, aber das ist Wortklauberei. Mir ist klar, dass die DB keine Exceptions werfen kann. Wenn ich von DB spreche, dann meine ich die DB-Verbindungsbibliothek (den "Layer").
Freilich kannst Du nach jedem einzelnen Statement auch ohne eine Exception auszulösen, prüfen, ob ein Fehler aufgetreten ist.
Du hast meinen Punkt nicht verstanden. Ich bin darauf eingegangen, welche Arten von Datenbank-Fehlern es gibt. Ich habe kein Problem mit Exceptions durch die Datenbank (bzw. den Layer, wenn du das lieber hören willst), ganz im Gegenteil: ich lasse mir auch Exceptions werfen, wenn die Datenbank eine Query nicht erfolgreich beenden konnte.
In zwei von drei von mir aufgezählten Fällen ist es aber keine Geschäftslogik, die zugrunde liegen. Es wird keine Geschäftslogik geben, wenn ich einen Bug in meine Queries reinbaue. Es wird keine oder nur wenig Geschäftslogik geben, wenn die Datenbank nicht erreichbar ist.
Der Ausnahmefall ist Fall (c): nämlich dann, wenn ich auf Verdacht eine Query absetze und die Datenbank mir dann mitteilt, ob es erfolgreich war. Als Beispiel habe ich einen UNIQUE-Constraint genannt, wird ja häufig gerne für fachliche Schlüssel eingesetzt sowas.
Beispiel (mal ganz plastisch): wir sind in der Kennzeichenzentrale. In der Kennzeichenspalte ist ein UNIQUE-constraint.
Ich versuche ein Autokennzeichen in die Datenbank einzutragen.
Möglichkeit (i): Ich locke die Tabelle, schaue nach, ob das Kennzeichen existiert. Wenn nein, dann schreibe ich das Kennzeichen rein. Wenn es existiert, dann behandle den Fall ("Kennzeichen existiert"). Entferne das Lock.
Möglichkeit (ii): Ich schreibe das Kennzeichen rein. Wenn die Datenbank einen Constraint-Fehler meldet, behandle ich den Fall ("Kennzeichen existiert").
_Das_ ist Geschäftslogik, und wenn du die DB (den DB-Layer) dazu bringst, aus "Nicht-erfolgreichen Queries" Exceptions zu machen, dann musst du Geschäftslogik mit Exceptions abhandeln.
Und noch ein Unterschied zwischen Fall (a)+(b) und (c):
Die Exceptions in den Fällen (a) und (b) wirst du doch eher global abarbeiten. D.h. "um dein ganzes Programm rum" wirst du ein try/catch-setzen, welches die Exception fängt und dann entsprechend dein Programm sauber herunterfährt oder sowas.
Im Fall (c) ist deine Exception-Verarbeitung aber sehr lokal. Du willst dann nämlich genau für ein Query wissen, ob es erfolgreich war. Aber dann hast du keinerlei Vorteil gegenüber einer einfachen Überprüfung auf den Rückgabewert des Queries, der Aufwand ist gleich hoch.
Bitte zeige mir noch mehr Fälle, in denen ein DB-Query nicht erfolgreich ist und nicht Fall (a) bis (c) eintritt. Und dann kann man auch (im Beispiel Exceptions durch DB) entscheiden, ob es sinnvoll oder nicht sinnvoll ist, Geschäftslogik durch Exceptions zu behandeln.
Bis die Tage,
Matti