{"id":55000069,"date":"2012-02-01T00:00:00","date_gmt":"2020-01-24T15:57:52","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=69"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Fehlerbehandlung_unter_VBA","status":"publish","type":"post","link":"https:\/\/access-basics.de\/index.php\/Fehlerbehandlung_unter_VBA.html","title":{"rendered":"Fehlerbehandlung unter VBA"},"content":{"rendered":"

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.<\/p>\n

Wozu eine Fehlerbehandlung<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Fehler ohne Fehlerbehandlung<\/h2>\n

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<\/b>-, dem .accdb<\/b>– oder einem anderen nicht geschützten Format vorliegt. Wenn die Datenbank als .mde<\/b>– oder .accde<\/b>-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!<\/p>\n

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

\"Fehlermeldung<\/a><\/p>\n

Bild 1: Fehlermeldung eines unbehandelten Fehlers<\/p>\n

Fehlerbehandlung von Laufzeitfehler<\/h2>\n

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 <\/b>innerhalb der Routine, aber vor der fehlerhaften Zeile ein. Ein Beispiel sieht so aus:<\/p>\n

Public Sub <\/span>DivisionDurchNullFehlerbehandlung()\r\n     On Error Resume Next<\/span>\r\n     Debug.Print<\/span> 1 \/ 0\r\nEnd Sub<\/span><\/pre>\n
Das Resultat dieser Vorgehensweise ist, dass der in der Zeile Debug.Print 1\/0 <\/b>auftretende Fehler einfach ignoriert wird. Dummerweise tut die Zeile aber auch nichts mehr.<\/p>\n
Im folgenden Beispiel tritt in der Zeile i = 32768 <\/b>ein überlauf auf (Fehler 6<\/b>). Die fehlerhafte Zeile wird nicht ausgeführt, i <\/b>wird also nicht mit dem angegebenen Wert gefüllt. Integer<\/b>-Variablen haben den Standardwert 0<\/b>, also gibt das Meldungsfenster den Wert 0 <\/b>aus:<\/p>\n
Public Sub <\/span>Ueberlauf()\r\n     Dim <\/span>i As Integer<\/span>\r\n     On Error Resume Next<\/span>\r\n     i = 32768\r\n     MsgBox<\/span> i\r\nEnd Sub<\/span><\/pre>\n
Das ist ein Problem, denn durch den übergangenen Fehler entsteht ein logischer Fehler: Obwohl i <\/b>eigentlich den Wert 32768 <\/b>enthalten sollte, liefert das Meldungsfenster den Wert 0<\/b>. Solche logischen Fehler entstehen oft, wenn man – teilweise aus Bequemlichkeit – einen Fehler mit On Error Resume Next <\/b>unterbindet.<\/p>\n
On Error Resume Next <\/b>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).<\/p>\n
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 <\/b>legt ein mit dem einzigen Parameter angegebenes Verzeichnis an. Wenn Sie diesen Parameter wie folgt verwenden, entsteht dadurch etwa das Verzeichnis Export <\/b>in dem Ordner, in dem sich auch die Datenbankdatei befindet (CurrentProject.Path <\/b>liefert den Datenbankpfad):<\/p>\n
MkDir CurrentProject.Path & \"\\Export\"<\/pre>\n
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).<\/p>\n
\"Ein<\/a><\/p>\n
Bild 2: Ein bereits vorhandenes Verzeichnis lässt sich nicht nochmals anlegen.<\/p>\n
Fehlerbehandlung deaktivieren<\/h2>\n
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 <\/b>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<\/b>. Wenn Sie die folgende Prozedur ausführen, löst das wiederholte Anlegen des Verzeichnisses keine Fehlermeldung aus, wohl aber die folgende Division durch 0<\/b>:<\/p>\n
Public Sub <\/span>VerzeichnisAnlegen()\r\n     On Error Resume Next<\/span>\r\n     MkDir CurrentProject.Path & \"\\Export\"\r\n     On Error GoTo<\/span> 0\r\n     Debug.Print<\/span> 1 \/ 0\r\nEnd Sub<\/span><\/pre>\n
Was also erledigt On Error Goto 0 <\/b>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 <\/b>besteht.<\/p>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t
\n\n\t\t\n\t\t