Excel programmieren

6 Fehlersuche und Fehlerabsicherung

Wo programmiert wird, da passieren Fehler! Diese Regel hat sich im Verlauf der letzten Jahrzehnte als unumstößlich herausgestellt. Selbst in jahrelang ausgereiften Programmen werden immer noch Fehler entdeckt. (Ganz zu schweigen von Programmen wie Excel oder Word, wo das Implementieren immer neuer Funktionen offensichtlich höhere Priorität hat als die Fehlersuche.) Ziel dieses Kapitels ist es aber nicht, über die Qualität vorhandener Software zu schimpfen, sondern Ihnen zu zeigen, wie Sie es besser machen können. Vielleicht kommt dann sogar Verständnis dafür auf, dass auch bei Microsoft Fehler passieren. Das Kapitel  gliedert sich in zwei Abschnitte: Der erste beschreibt die Möglichkeiten zur Analyse fehlerhafter Programme. Die englische Bezeichnung für diese Tätigkeit lautet "Debugging". VBA bietet zu diesem Zweck eine ausgezeichnete Arbeitsumgebung, die unter anderem die Schritt-für-Schritt-Ausführung von Programmen, bedingte Haltepunkte und die Überwachung von Variablen ermöglicht. Der zweite Abschnitt dieses Kapitels zeigt, wie Sie Ihr Programm gegen ein unkontrolliertes Verhalten absichern, wenn doch ein Fehler auftreten sollte (z. B. wenn der Anwender Ihr Programm falsch bedient).

6.1 Hilfsmittel zur Fehlersuche (Debugging)
6.1.1 Syntaxkontrolle

Fehler, die bereits vor dem Programmstart gemeldet werden VBA weigert sich, irgendeine Prozedur zu starten, solange es im Code noch formale Fehler feststellen kann. VBA erkennt dabei falsch oder gar nicht deklarierte Variablen (siehe unten), die fehlerhafte Verwendung von Schlüsselwörtern als Variablen- oder Prozedurnamen, den Versuch, eine gar nicht existente Prozedur aufzurufen, doppelt definierte Prozeduren, die irrtümliche Verwendung von ";" statt "," etc. Die meisten dieser Fehler sind einfach zu erkennen und mit wenig Aufwand zu beseitigen.

TIPP
Manche Fehler - etwa Tippfehler bei Methoden und Eigenschaften - können erst beim Kompilieren festgestellt werden (und unter Umständen sogar erst bei der Ausführung des Codes). In der Defaulteinstellung werden allerdings nur die Programmteile kompiliert, die tatsächlich benötigt werden. Daher kann es vorkommen, dass formale Fehler erst nach einiger Zeit, d.h., wenn die jeweilige Prozedur zum ersten Mal benötigt wird, entdeckt werden. Meistens ist es angenehmer, vor dem Programmstart alle formalen Fehler aufzuspüren. Dazu können Sie entweder das gesamte Projekt mit DEBUGGEN|KOMPILIEREN in Pseudo-Code umwandeln oder die beiden Kompiliereinstellungen in EXTRAS| OPTIONEN deaktivieren.
Fehler bei der Variablendeklaration
Wenn am Beginn Ihres Moduls die Anweisung Option Explicit steht, dann muss jede Variable vor ihrer Verwendung mit Dim, Private oder Public deklariert werden. Das sieht zwar nach zusätzlicher Arbeit aus, ist aber ein wichtiger und effizienter Mechanismus zur Vermeidung von Tippfehlern. Gerade bei den ungemein langatmigen Schlüsselwörtern (etwa der Methode ToolbarButtons) sind Tippfehler quasi schon vorprogrammiert. Ohne die Option Explicit interpretiert VBA ein falsch geschriebenes Schlüsselwort in der Regel wie eine nicht deklarierte Variant-Variable. Es kann ohne weiteres vorkommen, dass ein solches Programm trotz des offensichtlichen inhaltlichen Fehlers syntaktisch gesehen korrekt ist! Das Programm wird also anstandslos gestartet, womöglich tritt nicht einmal während der Ausführung ein Problem auf - wenn man davon absieht, dass die Prozedur den beabsichtigten Zweck nicht erfüllt.

Verwenden Sie daher immer die Option Explicit! Wenn Sie über EXTRAS|OPTIONEN| EDITOR die Option VARIABLENDEKLARATION ERFORDERLICH anklicken, dann fügt VBA bei allen neuen Modulen die Anweisung Option Explicit automatisch ein. (Die Option hat keinen Einfluss auf schon vorhandene Module.) Wenn Sie in Ihren Prozeduren den Typ der Parameter exakt angeben (das sollten Sie!), dann muss dieser Typ mit dem Typ der beim Aufruf übergebenen Variablen exakt übereinstimmen; andernfalls kommt es zu einer Fehlermeldung.