[SOUNDLIGHT]   PROGRAMMING CRASHKURS

Debugging:

Welcher Programmierer kennt das nicht. Das eigene Programm, in das man so viel Gedanken, Arbeit und Zeit investiert hat, ist endlich fertig. Viele Stunden lang hat man die letzten Fehler gesucht und bearbeitet, und jetzt ist es an der Zeit, es anderen Freunden oder Kunden zu zeigen.

Zu Hause läuft das Programm stabil und man erhofft sich endlich eine Bestätigung von andern.

Und jetzt wird das Programm auf einem anderen Rechner ohne "Aufsicht" installiert und gestartet, und ... außer einer blöden Fehlermeldung tut sich gar nichts, bevor der Bildschirm richtig aufgebaut wurde bricht das Programm schon wieder ab.

Typische Fehlermeldungen sind dann z.B. "File not found" oder "Property can not be set" oder sonst etwas, was man selber noch nie gesehen hat.

Zu dumm, an solche Fehler hat man einfach nicht gedacht, und natürlich dafür auch keine ausreichend gute Fehlerbehandlungsroutine geschrieben. Die Initialisierung des Programm nimmt viele Seiten in Anspruch und nun ist guter Rat teuer.



Oft liegt es nur daran, daß das Programm nicht aus dem Verzeichnis heraus gestartet wird, in dem die weiteren Dateien wie .ini oder .dll liegen. Am einfachsten läßt man eine Verknüpfung

auf dem Desktop anlegen, in dem auch die Arbeitsverzeichnis das entsprechen Verzeichnis eingetragen ist.

Außerdem habe ich jetzt eine Service Routine geschrieben, die mir die Fehlersuche zu mindestens auf kleinere Bereich begrenzt. Ich kann das Programm mit dem Kommandozeilenparameter "-service" aufrufen (da muß man z.B. die Verknüpfung auf dem Desktop in "D:\Verzeichnis\Programm.exe -service" ändern.



Nach jedem Abschnitt während der Initialisierung frage ich den Parameter ab und gebe dann eine MsgBox aus, in der angegeben wird, wie weit das Programm inzwischen fortgeschritten ist.

Die eigentliche Routine sieht in Visual Basic 3.0 so aus:

Diese drei Zeilen sagen mir jetzt schon einmal, wie weit ich gekommen bin.



So kann ich an verschiedenen Stellen eine erneute Abfrage einfügen und erhalte von dem Anwender eine entsprechende Rückmeldung, wo das Programm fehlläuft, und habe damit die Suche deutlich eingegrenzt. Unabhängig davon sollte man versuchen eine genauere Fehlebehandlung zur Laufzeit vorzusehen, Dateien die sich nicht öffnen lassen müssen zu mindestens den Namen der Datei zurückgeben etc.







Diese Meldung sieht dann der Kunde und kann eine entsprechend Rückmeldung geben.

.

Vielleicht konnte ich hiermit einen kleinen Tip geben, wie man das Debuggen beim Anwender etwas erleichtern kann.

Florian Behrendt

Kommentare?