Kunsmann Individual-Software - Visual-Basic Programmierung

Kontakt Anfahrtplan Datenschutzerklärung Impressum Englisch

Leistungen
Kundenservice
Software
Kunden

Suchen:

www.kunsmann.de

Das ganze Web

Service: Visual-Basic 6.0 Tipps: Fehlersuche und Fehlerbereinigung

Ein Hinweis vorab: Die hier beschriebene Technik ist wahrscheinlich nicht auf Anhieb zu verstehen. Beenden Sie ggf. Ihre Internet-Verbindung um Kosten zu sparen und lesen und testen Sie in aller Ruhe. Ich bin der festen Überzeugung, dass sich der Zeitaufwand für Sie lohnt.

Mit dem Direktfenster, dem Überwachungsfenster und dem Lokalfenster bietet VB gute Möglichkeiten für effektive Fehlersuche und Fehlerbehandlung. Trotzdem bleiben Wünsche offen, denn für eine bestmögliche Fehlerbeseitigung sind zwei grundlegende Informationen erforderlich:

Welcher Fehler ist aufgetreten (Nummer und Beschreibung)
An welcher Stelle im Code ist der Fehler aufgetreten

Insbesondere wenn ein Codefehler bei einem Schleifendurchlauf auftritt, ist die zweite Information mit Standard-VB-Mitteln oft nur mit Mühe und großem Zeitaufwand zu ermitteln. Mit Hilfe der Kombination verschiedener, hier beschriebener Techniken werden Sie in der Lage sein, bei jedem Fehler alle oben genannten Informationen ohne großen Aufwand zu erhalten.

Nachstehender Codeausschnitt zeigt die Technik:

' 17.09.00 - Ralf Kunsmann Public Sub ShowDebugMechanism() On Error GoTo ErrShowDebugMechanism Dim c As Integer For c = 0 To 65000 Debug.Print c Next CleanUp: Exit Sub ErrShowDebugMechanism: #If afDebug Then Debug.Print Err.Number & " - " & Err.Description Stop Resume #End If ' Show error message sMSG = "Fehler: " & Err.Number & " - " & Err.Description MsgBox sMSG, vbExclamation, Caption End Sub

Zuerst die Preisfrage: Wo ist der Fehler im Code? Die Antwort (Sie haben es natürlich auf den ersten Blick erkannt): Die Schleife läuft etwas zu lange für eine Kontrollvariable vom Typ 'Integer'. Es kommt unweigerlich zum Fehler. Als routinierter VB-Programmierer erkennen Sie anhand der Fehlermeldung 'Überlauf' (Nummer 6) natürlich sofort die Ursache und werden den Fehler in kürzester Zeit beheben.

Bei Codefehlern, die ähnlich gelagert, aber nicht ganz so offensichtlich sind, haben Sie es möglicherweise nicht so leicht, die Ursache herauszufinden. Hier kommt der Code im Errorhandler zu tragen.

Da wäre zunächst einmal die für die meisten Basic-Programmierer etwas ungewöhnliche '#If afDebug Then ... #End If'-Konstruktion. Was es damit auf sich hat, ist unter Verwendung von Kompilierzeitvariablen beschrieben.

Was passiert jetzt im Fehlerfall? Probieren Sie es aus. Kopieren Sie den Code in ein neues Projekt, definieren Sie 'afDebug' als Kompilierzeitargument und testen Sie, was passiert.

Sobald der Wert der Variablen 'c' größer wird, als es der Datentyp zulässt, springt der Code in die Fehlerbehandlung und gibt Fehlernummer und Fehlerbeschreibung ins Direktfenster aus. Danach wird die Ausführung des Codes durch die 'Stop'-Anweisung angehalten. Damit haben Sie die Gelegenheit, das Direktfenster zu aktivieren und die Art des Fehlers nachzulesen (verwenden Sie die Tastenkombination Strg-G, um unmittelbar ins Direktfenster zu wechseln). Jetzt wissen Sie, welche Art von Fehler aufgetreten ist (das hätten Sie auch einfacher haben können - aber abwarten ... ). Wenn Sie jetzt zwei Mal die Taste F8 drücken, steht der Cursor genau an der Stelle im Code, an der der Fehler aufgetreten ist. Und das ist der Witz an der Sache: Sie haben jetzt alle irgend wie verfügbaren Fehlerinformationen im Zugriff:

Welcher Fehler ist aufgetreten
An welcher Stelle im Code ist der Fehler aufgetreten
Welchen Status haben die Variable (Lokalfenster, Überwachungsfenster oder Direktfenster verwenden!)

Sie haben wahrscheinlich zwei wichtige Gründe, warum Sie diese Technik nicht einsetzen werden:

Es macht Ihnen zu viel Mühe, immer wieder diesen widerlichen, langweiligen Code in Ihre Routinen einzufügen
Sie wollen nicht, dass Ihre ausführbaren Dateien beendet werden, wenn ein Fehler auftritt, weil in der Fehlerbehandlung eine 'Stop'-Anweisung steht

Für den ersten Einwand habe ich bedingt Verständnis. Ich bind letztendlich auch faul und will mir nicht zuviel Arbeit machen ... aber im Ernst: Dieser Einwand kann nicht IHR ERNST sein. Ich bin der Meinung, dass die Vorteile, die mit diesem Mechanismus verbunden sind, den Aufwand in jedem Fall rechtfertigen. Aber wiederum: Machen Sie sich diese Arbeit bitte trotzdem nicht. Verwenden Sie statt dessen einfach meine 'VBExtensionTools'. Die nehmen Ihnen diese Arbeit ab, in dem vorbereitete Routinen (Sub oder Function) erstellt werden, die diese Art der Fehlerbehandlung beinhalten oder eine derartige Fehlerbehandlung in vorhandene Prozeduren einfügt.

Der zweite Einwand ist von gravierenderer Natur. Falls Sie ihn noch nicht verstehen, sehen Sie sich das Codebeispiel oben noch ein Mal ganz genau an. Sie werden folgendes erkennen: Wenn Sie den Code kompilieren, die ausführbare Datei erstellen und ausführen, wird das Programm sofort beendet, wenn der Fehler auftritt, da in der Fehlerbehandlung eine 'Stop'-Anweisung steht.

Die Abhilfe ist natürlich sehr einfach: Bevor Sie Ihr Projekt kompilieren, müssen Sie das Kompilierzeit-Argument 'afDebug = -1' zurücksetzen, damit im Fehlerfall nicht der Debug-(hilfs-)Code, sondern die Standard-Fehlerbehandlung (MsgBox) erscheint.

Es bleibt ein Problem: Auch wir Programmierer sind Menschen und machen Fehler und eines ist völlig klar: irgend wann werden Sie vergessen, 'afDebug' vor dem Kompilieren zurück zu setzen. Und etwas anderes ist ebenfalls klar: Diese Version der Software wird garantiert an Ihren Kunden ausgeliefert, denn ausgeliefert wird immer unter Zeitdruck und unter Zeitdruck passieren immer die schlimmsten Fehler. Aber das muss nicht sein: Stellen Sie sicher, dass das nicht passiert, indem Sie folgende Routine in Ihr Projekt einfügen:

#If afDebug Then Public Sub Dummy() ' !Reset 'afDebug' at compile time Call Anything End Sub #End If

Das hat zur Folge, dass Sie eine Fehlermeldung erhalten, wenn Sie das Projekt kompilieren. So sind Sie sicher, dass sie niemals Ihr Projekt kompilieren, wenn 'afDebug' nicht zurückgesetzt ist (sofern es in Ihrem Projekt keine Routine mit der Bezeichnung 'Anything' gibt ...).

Seitenanfang