{"id":55000779,"date":"2011-06-01T00:00:00","date_gmt":"2023-10-26T18:00:58","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=779"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Fehlerbehandlung_mit_vbWatchdog","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Fehlerbehandlung_mit_vbWatchdog\/","title":{"rendered":"Fehlerbehandlung mit vbWatchdog"},"content":{"rendered":"

\"\"<\/p>\n

Fehlerbehandlung ist für viele eine lästige Pflicht. Wenn man es richtig machen will, muss man jede einzelne Routine mit einer Fehlerbehandlung versehen. Dazu kommen noch Zeilennummern, Angabe des Modul- und Prozedurnamens und Informationen wie die Fehlernummer und Beschreibung. Die damit zusammenhängende Schreibarbeit kann man sich auf elegante Weise vom Hals schaffen – und mehr. Erreichen können Sie dies mit vbWatchdog – vier Klassenmodule und ein paar Zeilen Code sorgen für eine professionelle Fehlerbehandlung und wesentlich schlankere Prozeduren.<\/b><\/p>\n

+++ Frühlingsaktion +++
\n +++ Access [basics] Jahresabo
\n +++ plus eBook "Das Access 2003-Entwicklerbuch"
\n +++ 39,95 Euro statt 79,- Euro inkl. MwSt.!
\n+++ www.access-basics.de<\/a><\/p>\n

vbWatchdog <\/b>gibt es in zwei Versionen: Standard und Enterprise. Die Enterprise-Version enthält einige Features mehr, die den aktuellen Unterschied von 50% Aufschlag zum Preis der Standardversion mehr als rechtfertigen. Normalerweise werden in Access im Unternehmen<\/b> keine kostenpflichtigen Tools vorgestellt, aber wenn eines soviel Arbeit wie in diesem Fall sparen kann, machen wir eine Ausnahme.<\/p>\n

vbWatchdog <\/b>ist der deutlich verbesserte Nachfolger des SimplyVB6 – Global Error Handlers <\/b>des gleichen Herstellers. vbWatchdog <\/b>können Sie in beliebig viele Anwendungen einbauen. Preise für Mehrbenutzer-Lizenzen finden Sie auf der Webseite unter www.acciu.de\/watchdog<\/b>. <\/p>\n

Die Testversion von vbWatchdog <\/b>finden Sie unter dem gleichen Link. Nach dem Download starten Sie die .exe<\/b>-Datei, die ein COM-Add-In für den VBA-Editor installiert. Dieses fügen Sie im VBA-Editor über den Menüeintrag Add-Ins|vbWatchdog|Add vbWatchdog to this project <\/b>zum aktuellen VBA-Projekt hinzu (s. Bild 1).<\/p>\n

\"pic001.png\"<\/p>\n

Bild 1: Einfügen des vbWatchdog in ein VBA-Projekt<\/span><\/b><\/p>\n

Dies fügt dem aktuellen Projekt vier Klassenmodule hinzu, welche die komplette Funktionalität enthalten – es sind keine externen DLLs et cetera nötig (s. Bild 2). Sie geben vbWatchdog <\/b>also als Teil der Anwendung weiter.<\/p>\n

\"pic002.png\"<\/p>\n

Bild 2: Die vier Klassen des vbWatchdog<\/span><\/b><\/p>\n

Und damit kann die Fehlerbehandlung schon beginnen: Sie brauchen vbWatchdog <\/b>nur zu aktivieren und schon kümmert sich das Tool um alle auftretenden Laufzeitfehler. Die Aktivierung erfolgt im einfachsten Fall mit der folgenden Anweisung (eine Instanzierung der Klasse ErrEx ist nicht nötig):<\/p>\n

Public Sub vbWatchdogAktivieren()\r\n    Call ErrEx.Enable("")\r\nEnd Sub<\/pre>\n
Damit sorgen Sie dafür, dass vbWatchdog <\/b>im Fehlerfall seinen eingebauten Dialog anzeigt. Nehmen wir an, Sie starten bei aktiviertem vbWatchdog <\/b>die folgende Prozedur:<\/p>\n
Public Sub Testfehler()\r\n    Debug.Print 1 \/ 0\r\nEnd Sub<\/pre>\n
Die resultierende Fehlermeldung sieht dann wie in Bild 3 aus. Wenn Sie nicht mehr mit vbWatchdog <\/b>arbeiten möchten, deaktivieren Sie es mit der folgenden Anweisung:<\/p>\n
\"pic003.png\"<\/p>\n
Bild 3: Eine einfache Fehlermeldung des vbWatchdog<\/span><\/b><\/p>\n
ErrEx.Disable<\/pre>\n
Wenn Sie nicht die eingebaute Fehlermeldung von vbWatchdog <\/b>sehen wollen, können Sie selbst eine globale Fehlerbehandlungsroutine angeben. Dazu aktivieren Sie vbWatchdog <\/b>wie oben, geben aber den Namen der Prozedur an, die im Falle eines Fehlers aufgerufen werden soll:<\/p>\n
Public Sub vbWatchdogMitEigenerMeldung()\r\n    Call ErrEx.Enable("aiuFehlerbehandlung")\r\nEnd Sub<\/pre>\n
Die eigene Fehlerbehandlung soll in der Prozedur aiuFehlerbehandlung <\/b>erfolgen und sich zunächst einfach per Meldungsfenster zu Wort melden:<\/p>\n
Public Sub aiuFehlerbehandlung()\r\n    MsgBox "Fehler!"\r\nEnd Sub<\/pre>\n
Lösen Sie nun erneut einen Fehler aus, erscheint erst das Meldungsfenster und dann erneut der eingebaute Dialog von vbWatchdog<\/b>.<\/p>\n
Fehler protokollieren<\/b><\/p>\n
Die Fehlerbehandlungsprozedur aiuFehlerbehandlung<\/b> können Sie beispielsweise nutzen, um die Fehler in Tabellen zu dokumentieren. Dazu legen Sie zunächst eine einfache Fehlertabelle wie in Bild 4 an. Normalerweise würden Sie hier auch Informationen wie Projektname, Prozedurname, Modulname, Zeilennummer oder den Inhalt der fehlerhaften Zeile eintragen.<\/p>\n
\"pic004.png\"<\/p>\n
Bild 4: Tabellen zum Speichern von Fehlern …<\/span><\/b><\/p>\n
Nun bietet vbWatchdog<\/b> allerdings auch noch die Möglichkeit, Informationen aller Routinen auszugeben, die zum Auslösen des Fehlers geführt haben. Wenn also die Prozedur Testfehler2 <\/b>die Prozedur Testfehler1 <\/b>aufruft und diese wiederum die Prozedur Testfehler<\/b>, in der schließlich ein Fehler auftritt, dann kann es für den Entwickler von großem Nutzen sein, wenn er diesen Hergang kennt. Die Informationen dieses sogenannten Fehlerstacks liefert vbWatchdog <\/b>ebenfalls, weshalb wir diese Informationen in eine weitere, per 1:n-Beziehung mit der Tabelle tblFehler<\/b> verknüpfte Tabelle namens tblFehlerstack <\/b>auslagern (s. Bild 6.<\/p>\n
\"pic005.png\"<\/p>\n
Bild 5: … und der Schritte, die dazu führten.<\/span><\/b><\/p>\n
\"pic006.png\"<\/p>\n
Bild 6: Dokumentation eines einfachen Fehlers<\/span><\/b><\/p>\n
Variablen zum Fehlerzeitpunkt archivieren<\/b><\/p>\n
Wenn wir schon beim Archivieren sind, legen wir auch gleich noch eine dritte Tabelle zum Speichern der Variablen und ihrer Inhalte zum Zeitpunkt des Fehlers an. Diese sieht wie in Bild 7 aus und ist über das Feld FehlerstackID <\/b>mit der Tabelle tblFehlerstack <\/b>verknüpft.<\/p>\n
\"pic012.png\"<\/p>\n
Bild 7: Speichern der Variablen zum Zeitpunkt eines Fehlers<\/span><\/b><\/p>\n
Archivieren von Fehlern, Stack und Variablen<\/b><\/p>\n
Nun passen wir die Fehlerbehandlungs-Prozedur so an, dass sie die gewünschten Daten in die beiden Tabellen schreibt. Das Ergebnis sieht wie in Bild 6 zeigt, wie das für einen einfachen Fehler aussehen kann, der über drei Prozeduren angestoßen wurde.<\/p>\n
Listing 1: Speichern von Fehlerinformationen in drei Tabellen<\/p>\n
Public Sub aiuFehlerbehandlung()\r\n    Dim db As DAO.Database\r\n    Dim lngFehlerID As Long\r\n    Dim lngStackID As Long\r\n    Dim strSQLError As String\r\n    Dim strSQLErrorstack As String\r\n    Dim strSQLVariablen As String\r\n    Set db = CurrentDb\r\n    With ErrEx\r\n        strSQLError = "INSERT INTO tblFehler(Fehlerzeit, Fehlernummer, Fehlerbeschreibung) VALUES(" _\r\n            & ISODatum(Now) & ", " & .Number & ", ''" & .Description & "'')"\r\n        db.Execute strSQLError, dbFailOnError\r\n        lngFehlerID = db.OpenRecordset("SELECT @@IDENTITY").Fields(0)\r\n        With ErrEx.Callstack\r\n            Do\r\n                strSQLErrorstack = "INSERT INTO tblFehlerstack(Projektname, Modulname, Prozedurname, " _\r\n                    & "Zeilennummer, Zeileninhalt, FehlerID) VALUES(''" & .ProjectName & "'',''" _\r\n                    & .ModuleName & "'',''" & .ProcedureName & "''," & .LineNumber & ",''" & .LineCode _\r\n                    & "''," & lngFehlerID & ")"\r\n                db.Execute strSQLErrorstack, dbFailOnError\r\n                lngStackID = db.OpenRecordset("SELECT @@IDENTITY").Fields(0)\r\n                With ErrEx.Callstack.VariablesInspector\r\n                    .FirstVar\r\n                    Do While Not .IsEnd\r\n                        strSQLVariablen = "INSERT INTO tblVariablen(Variablenname, Variablenwert, " _\r\n                            & " Datentyp, Gueltigkeitsbereich, StackID) VALUES(''" & .Name & "'',''" _\r\n                            & .Value & "'',''" & .Type & "'',''" & .Scope & "''," & lngStackID & ")"\r\n                        db.Execute strSQLVariablen, dbFailOnError\r\n                        .NextVar\r\n                    Loop\r\n                End With\r\n            Loop While .NextLevel\r\n        End With\r\n    End With\r\nEnd Sub<\/pre>\n
Die Prozedur erledigt noch einen Schritt mehr (nur für die Enterprise-Version): Der vbWatchdog<\/b> liefert auch noch die Variablenwerte aller Variablen der Prozedur, die den Fehler ausgelöst hat, sowie aller Prozeduren, die sich im Stack befinden.<\/p>\n
Das Objekt für den Zugriff auf diese Informationen heißt ErrEx.Callstack.VariablesInspector<\/b>. Die erste Methode FirstVar <\/b>lädt die Informationen der ersten Variable, sodass diese über die Eigenschaften Name<\/b>, Value<\/b>, TypeDesc <\/b>(Datentyp) und Scop <\/b>(Gültigkeitsbereich) ausgelesen werden können. In einer Do While<\/b>-Schleife wird so oft die NextVar<\/b>-Methode ausgeführt, bis die Eigenschaft IsEnd <\/b>den Wert True <\/b>enthält – dann sind alle Variablen in die Tabelle tblVariablen <\/b>geschrieben.<\/p>\n
Die Fehlerinformationen können Sie natürlich auch in eine Text- oder XML-Datei schreiben oder im Direktfenster ausgeben.<\/p>\n
Fehlermeldung unterdrücken<\/b><\/p>\n
Die Fehlermeldung des vbWatchdog<\/b> unterdrücken Sie genau so, wie Sie es mit herkömmlichen Fehlermeldungen machen: Sie stellen der Zeile, die einen Fehler auslösen könnte, die folgende Anweisung voran:<\/p>\n
On Error Resume Next<\/pre>\n
Dies führt aber dennoch dazu, dass eine eventuell angegebene Errorhandler-Prozedur aufgerufen wird. Sie können also Fehler übergehen und dennoch die Fehlerinformationen aufzeichnen.<\/p>\n
Das Gleiche gilt, wenn Sie wie in folgendem Beispiel eine benutzerdefinierte Fehlermeldung ansteuern:<\/p>\n
Public Sub TestfehlerMitOnErrorGoto()\r\n    On Error GoTo Fehler\r\n    Debug.Print 1 \/ 0\r\nFehler:\r\n    MsgBox Err.Number & " " & Err.Description\r\nEnd Sub<\/pre>\n
Fehlerbehandlungen, die etwa das Einfügen doppelter Werte in eindeutig indizierten Tabellenfeldern abfangen sollen, behalten Sie so bei wie zuvor.<\/p>\n
Zeilennummern anzeigen<\/b><\/p>\n
Bei herkömmlicher Fehlerbehandlung konnten Sie mit der undokumentierten Erl<\/b>-Funktion die Nummer einer fehlerhaften Zeile abfragen, wenn die Zeilen der betroffenen Prozedur entsprechende Zeilennummern enthielten.<\/p>\n
vbWatchdog <\/b>liefert beim Auftreten eines Fehlers automatisch eine Zeilennummer, obwohl der VBA-Code gar keine Zeilennummern enthält.<\/p>\n
Wie kann das sein und muss ich jetzt von Hand durchzählen, in welcher Zeile der Fehler aufgetreten ist<\/p>\n
Nein: Sie brauchen einfach nur mit dem Menüeintrag Ansicht|Symbolleisten|vbWatchdog.LineNumberViewer <\/b>eine neue Symbolleiste hervorzuzaubern und den einzigen dort enthaltenen Befehl anzuklicken.<\/p>\n
Schon zeigt der VBA-Editor die Zeilennummern an (s. Bild 8).<\/p>\n
\"pic007.png\"<\/p>\n
Bild 8: Zeilennummern einblenden<\/span><\/b><\/p>\n
Eigenen Fehlerdialog programmieren<\/b><\/p>\n
Den Fehlerdialog von vbWatchdog <\/b>können Sie nach Ihren Wünschen anpassen. Am einfachsten gelingt das, wenn Sie die ebenfalls auf der Webseite des Herstellers verfügbare Beispieldatenbank namens vbWatchdog_Sample.mdb <\/b>starten und dort im Hauptformular auf Customize <\/b>klicken.<\/p>\n
Es erscheint ein Dialog, mit dem Sie alle verfügbaren Einstellungen vornehmen können (s. Bild 9).<\/p>\n
\"pic008.png\"<\/p>\n
Bild 9: Zusammenstellen eines benutzerdefinierten Fehlerdialogs<\/span><\/b><\/p>\n
Alle Einstellungen werden auf Knopfdruck zu einer Reihe von VBA-Anweisungen zusammengestellt und in die Zwischenablage kopiert.<\/p>\n
Sie fügen diese Anweisungen am besten in die gleiche Prozedur ein, die auch die Aktivierung des vbWatchDog <\/b>vornimmt. <\/p>\n
Die notwendigen Einstellungen nehmen Sie per VBA über zwei Objekte vor:<\/p>\n