Christoph Jüngling EDV

Vorwort

Die in diesem Artikel beschriebenen Mechanismen sind in Visual Basic 6 (VB6) sowie in Visual Basic for Appplications (VBA) einsetzbar. Sie gelten ausdrücklich nicht für VB-Dotnet, wo es bessere Alternativen (strukturiertes Try ... Catch ... Finally) gibt. In Anlehnung an diese neuen Mechanismen wurden die Labels der hiesigen Fehlerbehandlung jedoch bereits "Catch:" und "Final:" genannt.

Am "On Error Goto ..." lässt sich prinzipbedingt nichts ändern, und auf ein zu­sätzlich vorangestelltes Label "Try:" wurde wegen der Redundanz verzichtet. Wer mag, kann dieses jedoch gerne in der "On Error Goto"-Zeile ergänzen.

Einführung

Für die Fehlerbehandlung in VB(A)-Programmen gibt es grundsätzlich folgende Möglichkeiten:

1. Standardbehandlung über die Oberfläche
2. "On Error Goto Catch" mit Fehlerbehandlung in jeder Sub/Function
3. "On Error Goto Catch" mit Fehlerbehandlung in nur einer Sub/Function auf der obersten Ebene
4. "On Error Resume Next" mit unmittelbar folgender Fehlerüberprüfung mit "If Err.Number <> 0 Then" und sofortiger Fehlerbehandlung

Möglichkeit Nummer 1 scheidet grundsätzlich aus, da hier der Benutzer selten eine aussagekräftige Meldung bekommt und vor allem das Programm nicht sinnvoll weitergeführt werden kann. Außerdem bietet diese in der Regel die Option, mittels "Debug"-Button in den Programmcode zu wechseln, was auch in ungeschützten Access-Applikationen nicht unbedingt erwünscht ist.

Möglichkeit Nummer 2 ist sicherlich der Regelfall. Dieser hat jedoch den Nachteil, dass bei verschachteltem Funktionsaufruf ein gewisser Aufwand getrieben werden muss, um alle übergeordneten Subs/Funktionen ebenfalls ordnungsgemäß zu beenden. Dies kann z.B. über einen globalen Merker, einen zusätzlichen ByRef-Parameter oder das Funktionsergebnis geschehen. Hinzu kommt der Nachteil, dass auf übergeordneten Ebenen nicht mehr klar erkennbar ist, wo der Fehler ursprünglich her kam, was dessen Behebung erschwert.

Möglichkeit Nummer 3 hat zwar den Vorteil des sofortigen Abbruchs aller Ebenen, jedoch ist ein ordnungsgemäßes "Aufräumen" von Objektinstanzen nur unter Schwierigkeiten zu gewährleisten. Dies erfordert unter anderem durchgängig globale Variablen, was gemeinhin weitere Lesbarkeitsprobleme nach sich zieht.

Möglichkeit Nummer 4 scheidet meiner Ansicht nach aufgrund der schlechten Lesbarkeit aus und ist daher nur in VBScript zu vertreten, wo die anderen Varianten nicht möglich sind.

In Verbindung mit objektorientierter Programmierung tritt noch ein weiterer Aspekt zu Tage: Jede Klasse muss in sich abgeschlossen funktionieren, d.h. auch deren Aufräumarbeiten ("Terminator") müssen unabhängig von einem Fehler durchgeführt werden. Das Zerstören der Klasse muss zwar von außen ausgelöst werden, aber diese Funktion muss zu dem Zeitpunkt bereits über alle fehlerrelevanten Informationen verfügen, da diese nach der Zerstörung nicht mehr verfügbar wären.

Zur Lösung dieser Probleme bietet sich eine nähere Betrachtung des Exception-Handlings von VB(A) an.