TurboDB Engine Dokumentation

Fehlerbehandlung in TurboDB Native

Top  Previous  Next

Es besteht immer die Möglichkeit, dass die Ausführung eines TurboDB Befehls fehlt schlägt. Die Ursachen dafür gehen von der Verwendung falscher Argumente, über Verstöße gegen die Integrität der Datenbank und Tabellensperren, bis hin zu Hardware-Fehlern und vollen Speichermedien. Tritt ein derartiges Problem auf, löst TurboDB eine Exception aus. Die genaue Klasse dieser Ausnahme hängt von der verwendeten Bibliothek ab, unabhängig davon umfasst die Fehlerinformation vier wesentliche Bestandteile:

Exception Klasse

Es gibt eine Basisklasse für alle TurboDB Exceptions und einige abgeleitete Klassen für die diversen Fehlerkategorien. Abhängig von der verwndeten Bibliothek können auch Standard-Exceptions der Bobliothek auftreten (wie Tabelle muss geöffnet sein in der VCL Bibliothek oder Falscher Typ in .NET).

Codes für die Fehlerbeschreibung

Die Basisklasse der TurboDB Exceptions verfügt über einen Fehlercode, der die fehlgeschlagene Operation bezeichnet. Im folgenden Abschnitt findet sich eine Liste der Codes für die Fehlerbeschreibung und ihre Bedeutung.

Codes für die Fehlerursache

Die Basisklasse der TurboDB Exceptions verfügt auch über eine Eigenschaft, die den Grund des Fehlers angibt. Während beispielsweise die Fehlerbeschreibung lautet Index kann nicht erstellt werden,  kann der Code für die Fehlerursache entweder Indexdatei existiert bereits oder Index bereits geöffnet bedeuten. Der übernächste Abschnitt listet die Codes für die Fehlerursache und ihre Bedeutung.

Wichtige Regel zur Fehlerbehandlung

Gehen Sie nie davon aus den Grund für einen Fehler an einer bestimmten Code-Stelle zu kennen. Bei Verwendung einer Bibliothek für verbundenen Zugriff (z.B. VCL Tabellen oder das RecordSet unter .NET ) darf nie folgendes gemacht werden (Es handelt sich hier um Pseudo-Code, der von allen Programmieren zu verstehen ist):

try
ConnectedComponent.Post
catch
// Post schlägt fehl, weil der Anwender ungültige Daten eingegeben hat
ShowMessage('Die eingegebenen Daten sind ungültig, bitte korrigieren.');
end;

Das dürfen Sie so nicht machen, denn es kann and dieser Stelle viele andere Gründe für eine Exception geben und einige davon sollten nicht auf die leichte Schulter genommen werden: Auf einer Ebene kann die Kapazität des Speichermediums oder der Tabelle erschöpft sein, ein Index kann kaputt sein (wegen eines vorhergehenden Crashs), eine Datenbankdatei kann blockiert sein (beispielsweise durch einen Virenscanner). Auf einer anderen Ebene kann die Anwendung einen Fehler haben, die Komponente wurde nicht erzeugt, die Connection nicht geöffnet, der Datensatz nicht in den Editier- oder Anfügemodus versetzt, usw. In all diesen Fällen wird die gezeigte Fehlerbehandlung nicht nur Ihre Anwender behindern, sondern kann auch Auswirkungen auf die Integrität der Datenbank haben da man nicht in der Lage ist auf die eventuell fatalen Zustand zu reagieren. Eine korrekte Implementierung für obiges Beispiel sieht so aus (wieder in Pseudo-Code unter Verwendung verständlicher Bezeichner):

try
ConnectedComponent.Post
catch(TurboDBError Exc)
if Exc.ErrorCode = TdbErr_InvalidData then
   // Post schlägt fehl, weil der Anwender ungültige Daten eingegeben hat
   ShowMessage('The data you entered is invalid, please correct it.');
else throw;
end;

Jetzt wird die Meldung wirklich nur im vorhergesehenen Fall ausgegeben. Für alle anderen Ereignisse wird die Exception auf einer höheren Ebene behandelt oder zum Programmabbruch führen, was immer noch besser ist als den Fehler in einigen Fällen zu unterdrücken.

Obwohl sich diese Diskussion auf das Modell des sequentiellen Datenzugriffs konzentriert, ist die Essenz genauso auf den SQL-basierten Datenzugriff anwendbar. Obwohl Sie durch das Ausführen von SQL-Anweisungen keinen Einfluss auf die Integrität der Datenbank nehmen können, kann die Annahme den der Grund für eine Ausnahme im Voraus zu kennen, immer noch zu irreführenden Fehlermeldungen für den Benutzer und zu seltsamen Verhalten der Anwendung führen.