Christoph Jüngling EDV

Die Fehlerbehandlung wird oft sehr stiefmütterlich durchgeführt. Dabei gehen viele Programmierer wohl nach dem Motto vor, "Mein Programm macht keine Fehler!" Doch auch das beste Programm stößt irgendwann auf eine Situation, in der eine vernünftige Fehlermeldung an den Benutzer eine gute Idee wäre. Wenn wir das wirklich aussagekräftig machen, braucht uns der Kunde nur noch einen Screenshot zu schicken und wir können den Fehler nachvollziehen. Denn wir wissen genau, wo er aufgetreten ist.

Bevor wir in medias res gehen, möchte ich kurz auf die Frage eingehen, was überhaupt ein Fehler ist, welche Fehlerarten wir unterscheiden und wie unterschiedlich diese zu behandeln sind.

Fehlerarten

Wir unterscheiden in der Praxis zwischen den beiden folgenden Kategorien:

• Programmierfehler
• Laufzeitfehler

Programmierfehl er wiederum können unterschieden werden in

• Syntaxfehler
• logische Fehler

Vor Syntaxfehlern, also reinen Fehlern auf VBA-Code-Ebene, schützt uns der Compiler schon sicher. Was dieser nicht versteht, kann er schwerlich compilieren. Im Falle eines bestimmten Fallstrickes, der fehlerhaften Schreibweise von Variablennamen, können wir allerdings nur dann auf den Compiler vertrauen, wenn wir die Deklaration von Variablen als erforderlich gekennzeichnet haben.

Logische Fehler sind wesentlich schwieriger zu erkennen.

Und letztlich gegen die Laufzeitfehler können wir zum Zeitpunkt der Programmierung rein gar nichts unternehmen. Das ist sicher auch für Leute vorstellbar, die stets sagen "der Programmierer hat mal wieder geschlampt". Wäre ein Programmierer in der Lage, vorauszusagen wann eine bestimmte Datei aus dem Netzwerk verschwindet oder wann das Netzwerk einen Verbindungsfehler aufweist, dann würde er vermutlich auch die Lottozahlen vom kommenden Samstag kennen und brauchte nicht mehr zu programmieren.

Und gerade diese letzte Gruppe von Fehler ist es, für die w ir uns wappnen müssen. Diese wird dem Benutzer zwar leicht als unvermeidlich zu erklären sein, aber dennoch müssen wir möglichst für eine schne lle Behebung sorgen. Damit wir dies können, brauchen wir einige Informationen:

• Bei oder nach welcher Aktion ist der Fehler aufgetreten?
• Welcher Fehler ist aufgetreten (Nummer und Beschreibungstext)
• In welchem Programmteil ist der Fehler aufgetreten?

Was der Benutzer in dem Moment gerade gemacht hat, wird er uns sicher manchmal sagen können, manchmal jedoch nicht. Die anderen Informationen von ihm zu verlangen wäre vermessen, denn woher soll der Benutzer den Namen der Funktion kennen, wo der Fehler aufgetreten ist? Weil wir das aber nun mal wissen wollen, müssen wir den Benutzer in die Lage versetzen, uns diese Informationen zu liefern. Und genau darum geht es in diesem Artikel.