Der Umgang mit Fehlern in Microsoft Access

Ein Programm sollte so konzipiert sein, dass es auf auftretende Fehler möglichst sinnvoll reagiert, diese am besten jedoch verhindert.

Programmfehler

Um aufgetretene Fehler zu behandeln, bietet Access den On Error-Befehl an. Er bietet zum einen die Möglichkeit, im Fehlerfall zu einer Marke in der Sub/Function zu springen und den dortigen Code zur Fehlerbehandlung abzuarbeiten (On Error GoTo Sprungmarke), als auch die Option, den Fehler zu ignorieren und mit dem nächsten Kommando weiter zu machen (On Error Resume Next). Im Fehlerfall wird ein Objekt Err erzeugt, über das man ein paar Informationen zum aufgetretenen Fehler erhält.

Für die Fehlerbehandlung in Formularen kann man die Sub Form_Error im jeweiligen Formular verwenden, die eine Fehlernummer bereit stellt.

Ich formuliere “gefahrengeneigten” Code meistens in Funktionen und melde als Rückgabewert den Fehlerstatus (0=kein Fehler, alle anderen Werte sind Fehler). In der aufrufenden Sub/Function kann dann gegebenenfalls auf den zurück gegebenen Fehlercode entsprechend reagiert werden, ohne dass der Programmlauf abgebrochen wird.

Ich verwende eine allgemeine Fehlerbehandlungsroutine, die im Fehlerfall jeweils aufgerufen wird und den Fehler in vereinheitlichter Form ausgibt, z. B. über eine Messagebox.

Zusätzlich werden die aufgetretenen Fehler noch in ein Fehlerprotokoll geschrieben, so dass ich ggfs. noch eine Post-Mortem-Analyse durchführen kann. Leider werden Fehler ja auch nicht immer von den Anwendern gemeldet, so dass die gefühlte und die realeFehlerhäufigkeit voneinander abweichen können. Durch die Protokollierung der Fehler ist ggfs. auch eine statistische Auswertung der Fehler möglich, um die “Hot Spots” zu erkennen, in denen die meisten Fehler auftreten und wo die Entwickler-Zeit am sinnvollsten investiert werden sollte.

Ich habe drei Fehlerkategorien definiert. Die erste führt zum Programmabbruch nach Fehlermeldung und -protokollierung, die zweite zeigt den Fehler an und protokolliert ihn (ohne Programmabbruch) und die dritte protokolliert einen Fehler “still”.

Bei Anwendungen im betrieblichen Umfeld muss man hinsichtlich der Protokollierung den Aspekt der Leistungs- und Verhaltenskontrolle beachten.

Plausibilitätsprüfungen

Neben der Behandlung aufgetretener Fehler sollte nach meinem Verständnis auch die Vorbeugung von Fehlern implementiert werden. Ich baue daher Plausibilitätsprüfungen in meine Programme ein, die bei Auftreten von nicht prozesskonformen Werten oder Wertekombinationen einen Hinweis ausgeben oder ggfs. selbsttätig korrigieren (Jidoka).

Ein Beispiel dafür ist, dass ich z. B. das Erledigt-Flag in einer Erfassungsmaske automatisch setzen lassen, wenn ein Erledigungsdatum von Anwender eingegeben wurde. Ein anderes Beispiel ist die Prüfung eines Datumswertes mit der IsDate-Funktion auf Gültigkeit.

Je besser die Plausibilitätsprüfungen sein sollen, desto besser muss man natürlich den abgebildeten Prozess kennen und verstehen. Bei Prozessänderungen müssen die Plausibilitätsprüfungen jeweils angepasst werden.

Gerade in Formularen bietet Access bereits eingebaute Möglichkeiten zur Gültigkeitsprüfung für einzelne Eingabefelder an.

Je nach Schwere der verletzten Plausibilitätskriterien kann man es bei einer Meldung über die Plausibilitätsverletzung (Messagebox vom Typ vbInformation) belassen, die Plausibilität per Programmlogik herstellen, oder man erzwingt die Eingabe von plausiblen Daten (z. B. lässt sich vorher das Eingabeformular nicht schließen).

Hier muss die Balance zwischen der Datenkonsistenz und der “Freiheit des Anwenders” gefunden werden.

Weitere Massnahmen

Um Fehlbedienungen/Falscheingaben zu minimieren, bietet es sich an, möglichst nur die gerade relevanten Programmoptionen anzuzeigen. Ich blende beispielsweise je nach Programmsituation in Access-Formularen Optionen oder Buttons aus bzw. ein.

Neben der Behandlung von technischen und logischen Fehlern spielt auch die Benutzerfreundlichkeit eine wichtige Rolle, z. B. durch erwartungskonformes Verhalten des Programms.

Ein Programm sollte Idealerweise so gestaltet sein, dass der Anwender es gerne nutzt, auch wenn sich dies in der Praxis nicht immer umsetzen lässt.

#msaccess