Fehlerbehandlung unter VBA

Wer mit VBA arbeitet, wird früher oder später auf das Thema Fehlerbehandlung stoßen. Je komplexer Code wird und je mehr sein Ablauf von externen Faktoren beeinflusst wird, desto mehr sind sie auf eine Fehlerbehandlung angewiesen. Die Fehlerbehandlung sorgt dafür, dass der Benutzer nicht mit schwer interpretierbaren oder noch besser gar nicht mit Fehlermeldungen konfrontiert wird. Im Hintergrund hilft eine Fehlerbehandlung aber noch in vielen anderen Fällen, von denen der Benutzer gar nichts mitbekommt.

Wozu eine Fehlerbehandlung

Eine perfekte Anwendung arbeitet ohne Fehler. Perfekte Anwendungen sind jedoch selten, also treten auch Fehler auf. Zumindest der Benutzer einer Anwendung sollte jedoch den Eindruck erhalten, dass er mit einer perfekten Anwendung arbeitet – oder zumindest mit einer, die Fehler, wenn sie denn auftreten, entsprechend professionell verarbeitet.

Sprich: Besser, eine Anwendung wird im schlimmsten Fell beim Auftreten eine Fehlers kontrolliert beendet, als wenn sie unkontrolliert abstürzt – und am Ende sogar noch Daten verloren gehen.

Wenn unter VBA ein Fehler auftritt, geht das in der Regel beispielsweise mit dem Leeren von Objektvariablen einher. Wenn Sie also gerade eine globale Objektvariable mit einem Verweis auf ein Objekt wie ein Formular gefüllt haben und dann ein Fehler auftritt, wird die Objektvariable geleert. Mit der Folge, dass ein Zugriff auf das mit dieser Variable referenzierte Objekt ebenfalls zu einem Fehler führt.

Wenn Sie in einem solchen Fall eine Fehlerbehandlung verwenden, verhindern Sie zumindest den Folgefehler. Und Sie präsentieren dem Benutzer damit gegebenenfalls eine aussagekräftige Fehlermeldung statt einer von Access/VBA generierten Fehlermeldung, mit welcher der Benutzer oft nichts anfangen kann.

Dieser Artikel zeigt, wie Sie die unter VBA auftretenden Fehler so behandeln, dass Ihre Anwendung stabil weiterläuft und der Benutzer gegebenenfalls erfährt, was warum schief gelaufen ist.

Fehler ohne Fehlerbehandlung

Tritt ein Fehler ohne Fehlerbehandlung auf, löst dieser eine entsprechende Meldung aus und zeigt die fehlerhafte Stelle im Code an. Dies gilt jedoch nur, wenn Sie die Vollversion von Access verwenden und die Datei im .mdb-, dem .accdb– oder einem anderen nicht geschützten Format vorliegt. Wenn die Datenbank als .mde– oder .accde-Datenbank kompiliert wurde, also ihr Code nicht mehr im Entwurf eingesehen werden kann, erhalten Sie nur die Fehlermeldung mit Nummer und Text, können aber nicht mehr den fehlerhaften Code einsehen. Bei Verwendung der Runtime-Version von Access (mehr dazu in einem späteren Artikel) erhalten Sie nur noch eine allgemeine Fehlermeldung. Deshalb ist gerade in diesem Fall eine benutzerdefinierte Fehlerbehandlung sehr wichtig!

Die Meldung sieht beispielsweise wie in Bild 1 aus, weitere Beispiele und Grundlagen zu den verschiedenen Fehlerarten erhalten Sie im Artikel Fehler unter VBA.

Fehlermeldung eines unbehandelten Fehlers

Bild 1: Fehlermeldung eines unbehandelten Fehlers

Fehlerbehandlung von Laufzeitfehler

Im Gegensatz zu Syntax- oder Kompilierfehlern können Sie auf Fehler zur Laufzeit mit entsprechenden Anweisungen reagieren. Die einfachste Möglichkeit ist es, den Fehler einfach zu ignorieren. Dazu tragen Sie die Anweisung On Error Resume Next innerhalb der Routine, aber vor der fehlerhaften Zeile ein. Ein Beispiel sieht so aus:

Public Sub DivisionDurchNullFehlerbehandlung()
     On Error Resume Next
     Debug.Print 1 / 0
End Sub

Das Resultat dieser Vorgehensweise ist, dass der in der Zeile Debug.Print 1/0 auftretende Fehler einfach ignoriert wird. Dummerweise tut die Zeile aber auch nichts mehr.

Im folgenden Beispiel tritt in der Zeile i = 32768 ein überlauf auf (Fehler 6). Die fehlerhafte Zeile wird nicht ausgeführt, i wird also nicht mit dem angegebenen Wert gefüllt. Integer-Variablen haben den Standardwert 0, also gibt das Meldungsfenster den Wert 0 aus:

Public Sub Ueberlauf()
     Dim i As Integer
     On Error Resume Next
     i = 32768
     MsgBox i
End Sub

Das ist ein Problem, denn durch den übergangenen Fehler entsteht ein logischer Fehler: Obwohl i eigentlich den Wert 32768 enthalten sollte, liefert das Meldungsfenster den Wert 0. Solche logischen Fehler entstehen oft, wenn man – teilweise aus Bequemlichkeit – einen Fehler mit On Error Resume Next unterbindet.

On Error Resume Next sollten Sie also nur dort einsetzen, wo es nicht anders geht – oder dort, wo Sie vielleicht sogar einen Fehler provozieren möchten (hierzu später mehr).

Ein Beispiel für den sinnvollen Einsatz ist etwa das Anlegen eines Verzeichnisses im aktuellen Datenbankverzeichnis – beispielsweise, um dort Daten etwa im Excel-Format zu exportieren. Die Anweisung MkDir legt ein mit dem einzigen Parameter angegebenes Verzeichnis an. Wenn Sie diesen Parameter wie folgt verwenden, entsteht dadurch etwa das Verzeichnis Export in dem Ordner, in dem sich auch die Datenbankdatei befindet (CurrentProject.Path liefert den Datenbankpfad):

MkDir CurrentProject.Path & "\Export"

Das Dumme ist nur: Wenn Sie die Prozedur, in der sich diese Anweisung befindet, ein zweites Mal ausführen, ist das Verzeichnis bereits vorhanden; der erneute Versuch, dieses anzulegen, führt zu einem Fehler (siehe Bild 2).

Ein bereits vorhandenes Verzeichnis lässt sich nicht nochmals anlegen.

Bild 2: Ein bereits vorhandenes Verzeichnis lässt sich nicht nochmals anlegen.

Fehlerbehandlung deaktivieren

Nun gibt es zwei Möglichkeiten: Entweder Sie prüfen zuvor, ob das Verzeichnis schon vorhanden ist, oder Sie ignorieren einfach den Fehler beim erneuten Anlegen, indem Sie zuvor die Anweisung On Error Resume Next ausführen. Letzteres ist kein Problem, wenn Sie sehr vorsichtig damit umgehen. Das zieht in diesem Fall vor allem nach sich, dass Sie die Fehlerbehandlung unmittelbar im Anschluss an die betroffene Anweisung wieder so einstellen, dass Fehlermeldungen angezeigt werden! Dies erledigen Sie mit der Anweisung On Error Goto 0. Wenn Sie die folgende Prozedur ausführen, löst das wiederholte Anlegen des Verzeichnisses keine Fehlermeldung aus, wohl aber die folgende Division durch 0:

Public Sub VerzeichnisAnlegen()
     On Error Resume Next
     MkDir CurrentProject.Path & "\Export"
     On Error GoTo 0
     Debug.Print 1 / 0
End Sub

Was also erledigt On Error Goto 0 genau Es deaktiviert eine eventuell zuvor aktivierte benutzerdefinierte Fehlerbehandlung, die im einfachsten Fall nur aus dem Ignorieren von Fehlern durch die Anweisung On Error Resume Next besteht.

Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!
Hier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]:
Zur Bestellung ...
Danach greifen Sie sofort auf alle rund 400 Artikel unseres Angebots zu - auch auf diesen hier!
Oder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:

Schreibe einen Kommentar