Debugging ◦ ?

Entwicklungswerkzeuge können das Auffinden und Beheben von Fehlern erleichtern. Ein Debugger (“Entwanzer”) unterstützt zum Beispiel die systematische Fehlersuche und -korrektur. Die Entwicklerin kann die Ausführung eines Programms nach jeder Zeile anhalten und so Logikfehler (bugs oder “Wanzen”) besser identifizieren. Im Debugger kann die Entwicklerin insbesondere ...

1. einen beliebigen Programmausschnitt zeilenweise ausführen (stepwise debugging).

2. Haltepunkte definieren, an denen das Programm stoppt.

3. den Inhalt beliebiger Variablen inspizieren.

4. programmiersprachliche Überwachungsausdrücke definieren, die Programminhalte anzeigen.

### Ein Beispiel aus TESTS

Der folgende Ausschnitt aus einem Formular von Access_Quiz veranschaulicht Haltepunkte und Überwachungsausdrücke. Beim Lösen einer Mehrfachwahlaufgabe darf der Benutzer höchstens eine der vier Alternativen wählen (vgl. Gültigkeitsprüfung). Eine erste Version der Ereignisprozedur KkBenutzerlösung_Click() für ein Kontrollkästchen der Spalte 'Lösung' sei fehlerhaft, weil sie mehr als eine Markierung gestattet. Richtig ist KkBenutzerlösung_Click() erst, wenn die Benutzerin nach dem zweiten Markierungsversuch die Fehlermeldung "Markieren Sie nur e i n e Alternative" erhält.

Wir zeigen, wie der Debugger die Korrektur dieses logischen Fehlers erleichtert. Der nächste Bildschirmausschnitt stammt aus der Entwicklersicht von Access und illustriert die folgenden Debuggingschritte:

1. Die Entwicklerin setzt einen braunen Haltepunkt auf jenen Programmteil, in welchem sie den Fehler vermutet.

2. Die Entwicklerin führt den fehlerhaften Teil des Programms aus der Benutzersicht aus. In unserem Beispiel ist dies ein zweiter Markierungsversuch (siehe Bildschirmausschnitt oben).

3. Sobald das Programm den Haltepunkt betritt, wechselt Access automatisch von der Benutzer- zur Debuggersicht. Der folgende Bildschirmauschnitt zeigt die Debuggersicht.

4. Die Entwicklerin kann durch wiederholtes Drücken der Taste »F8 den Code Zeile für Zeile ausführen. Der Debugger markiert die laufende Zeile gelb.

5. Sobald die Entwicklerin mit dem Cursor auf einer Variable verweilt, erscheint deren Wert in einem hellgelben Kästchen.

Die laufende Codezeile und das Variablenkästchen [KkBenutzerlösung] = -1 legen die folgende Diagnose nahe: Nach Spezifikation müsste das Programm die äussere und die innere If-Anweisung betreten und mit MsgBox eine Fehlermeldung anzeigen. Dies geschieht nicht, weil der Code [KkBenutzerlösung] = False nicht auf den Wert True des im ersten Bildschirmausschnitt markierten Kontrollkästchens zutrifft. Die Entwicklerin realisiert erst jetzt, dass die Variable [KkBenutzerlösung] nach einem Klick auf ein leeres Kontrollkästchens bereits den Zustand nach dem Klickereignis - also das Markierungszeichen bzw. den Wert True - anzeigt. Sie korrigiert deshalb den Code der If-Bedingung in [KkBenutzerlösung] = True. Die Fortsetzung des Tests zeigt, dass sie die Ereignisprozedur erfolgreich "entwanzt" hat.

### Vorausschauende Fehlerbehandlung

Meist kann die Entwicklerin nicht alle möglichen Fehler vorausschauend vermeiden. Die meisten Programmiersprachen bieten deshalb die Möglichkeit, Fehlerbehandlungscode einzufügen, der die Auswirkungen von Fehlern minimiert, die zur Laufzeit auftreten (zum Beispiel das Öffnen einer nicht existierenden Datei). Mehr Informationen zur Fehlerbehandlung in Access und Visual Basic erfahren Sie unter Fehlerbehandlung.

Programmierfehler liegen nicht immer in der Verantwortung des Entwicklers. Oft sind auch Werkzeugmängel verantwortlich. Erkundigen Sie sich deshalb auf der Website des Entwicklers über bekannte Werkzeugfehler. TESTS kommentiert solche Tool Bugs mit dem Präfix '??.

Debugging unter MS Access