Letzte Änderung am 15. April 2023 by Christoph Jüngling
Fehler macht jeder mal, das ist menschlich. Und da Programme schließlich auch von Menschen gemacht werden, enthalten auch diese gelegentlich Fehler. Dagegen kann man zwar einiges tun, aber ganz vermeiden lässt es sich wohl nicht. Aus diesem Grunde sollte man vorbeugen, damit nichts passiert, wenn doch mal was passiert.
Wie ich in meinem Artikel Fehlerbehandlung ausführlich dargelegt habe, lässt sich schon mit Bordmitteln von z.B. Access einiges erreichen. Das setzt zwar eine erkleckliche Anzahl an zusätzlichen Programmzeilen voraus, aber diese einzufügen ist mit einem Hilfsmittel wie z.B. den MZ-Tools kein großer Akt. Das beschriebene Konzept ist auch ziemlich ausgereift, da wird es wohl kaum noch Überraschungen geben. Das dort Gesagte gilt grundsätzlich für alle Programme, die VBA unter der Haube haben, und ebenso auch für VB6, denn es kommt – abgesehen von der Unterstützung beim Einfügen des Codes – ohne zusätzliche Hilfsmittel aus.
In diesem Artikel
Nachteile des alten Konzeptes
Doch das Konzept hat auch seine Nachteile. Zunächst mal ist der schon angesprochene Aufwand an Codezeilen zu nennen. Dabei geht es gar nicht um die nackte Zahl, sondern in erster Linie um die Übersichtlichkeit. Es ist durchaus schon vorgekommen, dass der Code für die Fehlerbehandlung umfangreicher war als die Anweisungen, um die es eigentlich geht.
Ein weiterer Nachteil ist, dass dieses Hin- und Hergespringe zur Fehlerbehandlung und zurück zum finalen Teil der Funktion im ersten Moment etwas unübersichtlich ist. Leider kennt weder VBA noch VB6 das Konzept “Try – Catch – Final”, wie es aus verschiedenen anderen Programmiersprachen bekannt ist – und das, obwohl “Strukturierte Programmierung” und “Objektorientierung” doch eigentlich schon lange zum Standard gehören sollten.
Und wenn der Entwickler vergisst, auf der obersten Ebene (Formular, Bericht oder Main-Funktion) statt “RaiseSavedError” die Funktion “ShowSavedError” aufzurufen, dann muss der User doch wieder die nicht besonders elegante Meldung des Laufzeitsystems ertragen. Und er kommt schlimmstenfalls sogar mittels “Debug”-Button in den Code selbst hinein!
Die Alternative “vbWatchDog”
Mit vbWatchDog lassen sich die Vorteile einer lückenlosen Fehlerbehandlung nutzen, wobei die oben dargestellten Nachteile vermieden werden. Davon abgesehen erhalten wir sogar noch zusätzliche Vorteile, die in meiner Bordmittel-Lösung nicht enthalten sind (und sich dort auch nur mit erheblichem Aufwand einbauen ließen).
Lizenz
VbWatchDog ist eine lizensierte Software von EverythingAccess.com. Die einmaligen Kosten starten bei 145 € 200 € (Stand 4.1.2022) für die Enterprise-Edition, einen einzelnen Entwickler mit Basis-Support und ohne weitere Updates bis hin zu einer Site License mit 1 Jahr Premium-Support und Updates in der Ultimate Edition (also incl. VB6) für 2350 € (Stand 4.1.2022). Dazwischen sind viele Kombinationen machbar (siehe Purchase Options), so dass sicher jeder etwas passendes für sich findet. Eine (nach meiner Kenntnis unbefristete) Testversion ist ebenfalls verfügbar, sie meldet sich lediglich mit einem Nag-Screen bei jedem Start, scheint ansonsten aber voll funktionsfähig zu sein. Diese habe ich auch für diesen Artikel verwendet.
Im Hinblick auf die Lizenz muss einiges bei der Entwicklung und Weitergabe bedacht werden. Der Entwickler darf den Quellcode des vbWatchDog (technisch sind das nur eine Handvoll Klassenmodule) im Rahmen seiner Applikation an beliebig viele Anwender weitergeben. Nach Rücksprache mit dem Entwickler ist es jedoch nicht gestattet, diesen Code in die Quellcodeverwaltung einzuchecken! Dennoch gibt es dafür eine Lösung, die ich im zweiten Teil dieser Artikelserie nochmal aufgreifen werde.
Integration und Aktivierung
Nach dem Download und der Installation auf dem Entwicklungsrechner erhält man im VB-Editor:
Plugin-Menü des vbWatchDog (Trial-Version) im VB-Editor
Mit dem Befehl “Add vbWatchdog to this project” werden alle notwendigen Klassenmodule hinzugefügt, und das ist im Grunde auch alles, was man unbedingt braucht. Die Module beginnen alle mit der Zeichenfolge “ErrEx”, was für die oben genannte Einschränkung bezüglich der Versionsverwaltung sehr hilfreich ist.
Danach muss nur noch eine Zeile Code hinzugefügt werden, und schon ist der Wachhund aktiv und bellt los falls nötig:
ErrEx.Enable
Mehr braucht man nicht. Je eher diese Zeile ausgeführt wird, um so besser. Es bietet sich also an, dies im Rahmen der aus dem AutoExcec-Makro heraus ausgeführten Aktionen zu tun – alternativ im OnLoad-Ereignis des Startformulars.
Von diesem Moment an werden alle auftretenden Laufzeitfehler von WatchDog abgefangen und in Form eines Meldungsfensters zur Kenntnis gebracht:
Beispiel-Fehlermeldung mit vbWatchDog
Abgesehen von der vollständigen Source Line (nur in accdb, nicht accde!) haben wir noch keine Informationen, die nicht auch in meinem alten Konzept möglich gewesen wären. Interessant wird es allerdings über den Button “Show Variables”:
Variablen
Hier werden sowohl die jeweils verfügbaren lokalen, als auch die globalen Variablen aufgeführt, und das mit ihren aktuellen Werten! Das ist spannend, oder? Noch interessanter wird es (wenngleich das im Grunde zuvor auch schon ging), wenn der Button “More Info” angeklickt wird:
Call Stack
Wir wissen nun, wo genau der Fehler aufgetreten ist, wie er heißt, wie wir dort hin gekommen sind und welcher Zustand (Variablen) zu dem Fehler geführt hat. Und das ist es, was ich auch mit meinem alten Konzept erreichen wollte: Zur Laufzeit so viele Informationen wie nur möglich sammeln und dem Entwickler zur Verfügung stellen. Das ging damals gut, aber jetzt geht es noch viel besser.
Versionsverwaltung
Nun noch kurz zu dieser Besonderheit. Wie schon erwähnt dürfen die Klassenmodule des vbWatchDogs aus Lizenzgründen nicht in der Quellcodeverwaltung erfasst werden (Ergänzung: außer alle Entwickler verfügen über eine Lizenz). Mit Git lässt sich das sehr einfach erreichen, indem man eine Datei .gitignore im Hauptverzeichnis des Projektes anlegt. Darin werden die “ErrEx”-Dateien einfach als zu ignorierend aufgeführt. Von nun an meldet Git oder TortoiseGit nicht mehr, dass diese Dateien neu oder verändert worden seien. Dafür ist die erste Zeile in diesem Beispiel zuständig:
app/source/M_ErrEx*.def *.accd? *.laccd? *.bak *.lnk
Da ich mit OASIS arbeite, sieht das Datenmuster bei mir etwas anders aus als erwartet, und ich ignoriere diese Dateien auch nur in einem bestimmten Verzeichnis. Das kann und sollte man natürlich an die konkreten Gegebenheiten des eigenen Projektes anpassen, aber ich denke, das Prinzip ist klar geworden.
Falls der Windows-Explorer älterer Versionen sich übrigens weigert, einen Dateinamen mit einem Punkt beginnen zu lassen, geht das trotzdem, und zwar über die Komandozeile durch den Befehl echo >.gitignore. Danach kann man die Datei auch auf der GUI wieder z.B. mit Notepad bearbeiten.
Demnächst mehr zu diesem Thema, stay tuned :-)
Weitere Artikel zum Thema “vbWatchDog” findet ihr über das Tag vbWatchDog. Irgendwie naheliegend, oder? :-)
1 Kommentar
Interessantes Thema!
Ich bin sehr an dem Folgeartikel mit deinem Lösungsansatz zu vbWatchdog und Quellcodeverwaltung interessiert.