|
|
Bugfixes am Forum
Subdomains aktiviert
Counterscript entfernt
|
| |
|
 |
Benutzerhandbuch |
 |
|
Kapitel 6
Fehlermeldungen & der Debugger
·Fehlermeldungen des Compilers
·Laufzeitfehler
·Der Blitz2-Debugger
·Anzeige-Optionen
·Verfolgung des Programmablaufs
·Wiederaufnahme des normalen Ablaufs
·Der Befehlspuffer
·Der Direktmodus
·Fehlermeldungen des Debuggers
Fehlermeldungen des Compilers
Blitz2 erzeugt zwei unterschiedliche Kategorien von Fehlermeldungen: Übersetzungsfehler und Laufzeitfehler. Übersetzungsfehler treten während des Compilierens (Übersetzen) des Quellcodes auf, Laufzeitfehler treten während der Ausführung (Run time) des Programms auf.
Tritt während des Compilierens ein Fehler auf, so erscheint eine Nachricht im Editor. Wird OK angeklickt, so wird zu der Zeile im Programm zurückgekehrt, die den Fehler hervorgerufen hat.
In Anhang 2 des Blitz2 Referenz-Handbuchs befindet sich eine vollständige Beschreibung aller Compilermeldungen. Im folgenden wird auf einige der häufigsten Fehlerquellen hingewiesen:
· Beim Aufruf einer internen Blitz2-Funktion (also eines Befehls, der einen Wert zurückliefert) müssen die Parameter immer in Klammern eingeschlossen werden:
If ReadFile (0,"ram:test")
· Im Gegensatz dazu dürfen beim Aufruf von internen Blitz2-Befehlen, die keine Funktionen sind, die Parameter nicht in Klammern erscheinen:
BitMap 0,320,256,3
· Die Angabe eines Typ-Zusatzes beim Zugriff auf Elemente eines NewType führt zu der Meldung "Garbage at end of line" ("Schrott am Ende der Zeile"):
person\name$="Harry" ; zur Fehlerbehebung das $-Zeichen weglassen
· Der Daten-Typ einer numerischen Variable kann sich nicht ändern. Die Angabe eines anderen Typ-Zusatzes als des ursprünglichen führt zu der Meldung "MisMatched Type" ("Nicht-gleichwertige Datentypen"). Eine Ausnahme bilden String-Variablen.
Es gibt natürlich hunderte von möglichen Fehlern, die zu einem Abbruch des Compilierens führen, aber die meisten sind auf einfache Syntax-Fehler zurückzuführen und lassen sich schnell durch einen Blick in das Referenz-Handbuch klären. Of ist auch ein Vergleich mit den Beispielprogrammen hilfreich.
Außerdem gibt es noch die Help-Taste, die eine schnelle Überprüfung der Befehls-Syntax ermöglicht.
Die Anweisung CERR
Bei dem Gebrauch von Makros und bedingter Compilierung ("conditional compiling") kann es nützlich sein, eigene Compilermeldungen zu erzeugen.
Hierzu wird die CERR-Anweisung benutzt. Das folgende Beispiel führt dazu, daß der Compiler anhält und die Meldung "Muß 3 Parameter haben" ausgibt:
CERR "Muß 3 Parameter haben"
Im Kapitel 9 ist das bedingte Compilieren und die CERR-Anweisung eingehender beschrieben.
Laufzeitfehler
Unter Laufzeitfehlern ("run time error") versteht man solche Fehler, die während der Ausführung des Programms auftreten.
Während der Entwicklungsphase eines Programms sollte der Runtime Error Debugger immer aktiviert sein. Dies geschieht über das Compiler Options Menü. Ist der Debugger nicht aktiviert und es tritt ein Laufzeitfehler auf, stürzt das System ab.
Falls aus Geschwindigkeitsgründen die Überprüfung der Laufzeitfehler ausgeschaltet sein muß, sollte eine SetErr-Anweisung eingefügt werden, um einen Systemabsturz zu vermeiden. Das System kehrt dann zu der Programmzeile hinter der SetErr-Anweisung zurück.
Es ist empfehlenswert, die folgende Zeile am Anfang des Programms einzufügen:
SetErr:End:End SetErr
Eine der häufigsten Fehlerursachen ist der Zugriff auf Dateien, die entweder nicht vorhanden oder vom falschen Typ sind. Daher sollten Programme, die auf Dateien zugreifen, grundsätzlich immer eine der genannten Methoden der Fehlererkennung verwenden.
Ebenso sollten alle Programme, die Betriebssystem-Aufrufe verwenden, immer die Fehlerüberprüfung benutzen, da Bildschirm- und Window-Zugriffe manchmal an Speichermangel scheitern.
Ein Error Handler (Fehlerbehebungs-Routine) kann auch auf einen bestimmten Programmabschnitt beschränkt werden, dazu wird die Sequenz "SetErr...errohandler...EndSetErr" am Anfang und "ClrErr" am Ende des Abschnitts eingefügt.
Im folgenden Beispiel blinkt der Bildschirm auf, wenn der Aufruf von LoadShapes scheitert:
SetErr
DisplayBeep_ 0
End
EnsSetErr
LoadShapes 0, "dateiname"
ClrErr
Der Blitz2-Debugger
Tritt ein Laufzeitfehler in einem Programm auf, das vom Editor aus gestartet wurde, so wird der Debugger aktiviert, vorausgesetzt er wurde im 'Compiler Options' Menü eingeschaltet.
Ist in dem Programm selbst schon ein Error Handler aktiv, so wird der Debugger nicht aktiviert.
Der Debugger kann auch durch die Ctrl/Alt-C-Tastenkombination aktiviert werden. Außerdem dient der STOP-Befehl dazu, das Programm zu unterbrechen und den Debugger aufzurufen.
Der Debugger ist ein unentbehrliches Werkzeug bei der Fehlersuche. Seine Fähigkeit, von einer Stelle aus rückwärts durch den Programmcode zu gehen, der vorher ausgeführt wurde, bietet eine ausgezeichnete Möglichkeit, Fehler zu lokalisieren.
Alle Befehle des Debuggers werden aufgerufen, indem die Ctrl- und die linke Alt-Taste gleichzeitig mit der Taste für das Kommando gedrückt werden. Es gibt zwei verschiedene Arten von Kommandos: solche die immer während des Programmlaufs verfügbar sind und solche, die nur dann verfügbar sind, wenn das Programm gestoppt wurde.
Wenn ein Laufzeitfehler auftritt, wird automatisch das 'Keylock' eingeschaltet. Keylock bedeutet, daß die Ctrl/Alt-Kombination nicht mehr betätigt zu werden braucht um die Debugger-Kommandos aufzurufen (näheres s.u. unter K der nachfolgenden Liste).
Folgende Kommandos sind grundsätzlich immer verfügbar:
C - Programm anhalten
H - Hide: Debugger-Fenster zeigen/verstecken
V - View: Graphiken hinter dem Debugger-Fenster sichtbar machen oder verdecken
M - Mode: Umschalten zwischen hochauflösendem (hires) und niedrigauflösendem (lores) Graphikmodus wenn V aktiviert wurde
Die folgenden Kommandos sind nur dann verfügbar, wenn das Programm angehalten wurde:
Q - Quit: Programm beenden, auch über die ESC-Taste (hat dieselbe Auswirkung wie der Befehl END).
R - Run: Programm normal ablaufen lassen.
T - Trace: Ablaufverfolgung starten.
S - Single Step: Programm im Einzelschritt-Modus laufen lassen.
I - Ignore: Den aktuellen Befehl überspringen.
L - Umschalten der Ebene in der Ablaufverfolgung für das S- und T-Kommando. Hiermit kann über Gosubs, Prozeduren und For..Next-Schleifen hinweggegangen werden.
B - Back: Zurückpositioneren im Befehlspuffer zum zuvor ausgeführten Befehl.
F - Forward: Vorwärtspositionieren im Befehlspuffer zum nächsten ausgeführten Befehl.
E - Evaluate: Den Wert eines Ausdrucks kontrollieren. Der Wert wird im Debugger-Fenster angezeigt.
X - Execute: Einen Befehl ausführen.
K - Keylock: Umschalten des Keylock-Modus. Ist der Keylock-Modus eingeschaltet, wird die Ctrl/Alt-Kombination nicht benötigt um Debugger-Kommandos einzugeben. Es genügt dann die entsprechende Kommando-Taste.
Besonderheiten des Debuggers
Anzeige-Optionen
Die Anzeige des Debuggers erscheint immer als vorderstes Fenster, über allen anderen `Screens`. Im Blitz-Modus erschient sie über allen 'Slices'. Die Kommandos H, V und M beeinflussen die Anzeige-Optionen.
Das Kommando H (Hide) schaltet die Anzeige ein oder aus, V (View) schaltet die Anzeige auf "durchsichtig", sodaß der Hintergrund ebenfalls gesehen werden kann.
Das Kommando M (Mode) ist nur von Bedeutung, wenn V aktiviert wurde. Es schaltet dann den Hintergrund zwischen hochauflösender und niedrigauflösender Graphikdarstellung um. Da im Transparent-Modus nur zwei Bit-Ebenen dargestellt werden können, ist die Darstellung nicht immer perfekt, reicht aber aus um einen Überblick zu erhalten.
Verfolgung des Programmablaufs
Der Debugger ermöglicht es, die Ausführung der einzelnen Befehle eines Programmes zu verfolgen. Dabei wird der zur Zeit ausgeführte Befehl im Debugger-Fenster angezeigt.
Das Kommando S (Step) dient dazu, im Einzelschritt-Modus durch das Programm zu gehen. Jedesmal wenn S gedrückt wird, führt der Debugger den Befehl aus, auf den der Pfeil gerade zeigt und hält wieder an.
T (Trace) läßt den Debugger die Befehle kontinuierlich ausführen und anzeigen. Mit der Eingabe von C kann das Programm angehalten werden.
Mit L (Level) wird die Ebene der Ablaufverfolgung umgeschaltet. Ist L aktiv, werden die Schritte einer For..Next-Schleifen nicht einzeln angezeigt, sondern die Schleife wird bis zu ihrem Ende ausgeführt. Außerdem werden Prozedur-Aufrufe wie ein normaler Befehl behandelt, es wird also nicht in Prozeduren "hineingesprungen". Dies ist hilfreich, wenn z.B. die Arbeitsschleife des Hauptprogramms verfolgt werden soll, ohne daß die Ausführung der einzelnen Unterprogramme angezeigt wird.
Wiederaufnahme des normalen Ablaufs
Um das Programm normal weiterlaufen zu lassen, dient das Kommando R (Run).
Wenn der Debugger mit dem STOP-Befehl aktiviert wurde, zeigt der Pfeil auf die Zeile mit dem STOP. Dieser Befehl muß zunächst mit dem Kommando I (Ignore) übersrpungen werden. Das gleiche gilt für alle Befehle, die einen Laufzeitfehler verursacht und dadurch den Debugger aktiviert haben.
Um den Debugger zu verlassen und wieder in den Editor zurückzukehren, wird entweder das Kommando Q (Quit) oder die ESC-Taste benutzt.
Der Befehlspuffer
Der Debugger "merkt" sich alle Befehle, die der Rechner ausgeführt hat bevor das Programm angehalten wurde, in einem speziellen Puffer. Mit den Kommandos B und F kann sich der Benutzer in diesem Puffer "bewegen".
Mit dem Kommando B (Backup) können rückwärts die zuvor vom Rechner ausgeführten Befehle angesehen werden und zwar von der Stelle aus an der das Programman angehalten wurde. Die aktuelle Position in diesem Puffer wird mit einem "Hohlpfeil" angezeigt.
Das Kommando F (Forward) läßt den Benutzer in dem Befehlspuffer vorwärts gehen. Wenn versucht wird, über die Stelle, an der das Programm angehalten wurde, hinauszugehen, erscheint die Meldung "At End of Buffer" ("Ende des Puffers erreicht").
Diese Möglichkeit, die vor dem Auftreten eines Fehlers ausgeführten Befehle nachträglich verfolgen zu können, ist von unschätzbarem Wert. Wenn ein Programm innerhalb eines Unterprogramms oder einer Prozedur gestoppt wurde, kann somit ermittelt werden, von welcher Stelle im Hauptprogramm aus die Routine gerufen wurde.
Der Direktmodus
Der Programmierer hat zwei Möglichkeiten, den internen Zustand des Programms zu kontrollieren und zu beeinflussen, wenn der Debugger aktiv ist.
Um herauszufinden, welchen Wert eine Variable gerade besitzt, wird das Kommando E (Evaluate) verwendet. Nach der Eingabe von E wird der Benutzer aufgefordert, den Variablennamen einzugeben. Anschließend wird der Wert der Variablen angezeigt.
Mit dem Kommando X (Execute) können Blitz2-Befehle ausgeführt werden. Nach der Eingabe von X erscheint ein Prompt und es kann ein beliebiger Befehl eingegeben werden, wie z.B. CLS oder n=20.
Fehlermeldungen des Debuggers
Bei der Ausführung der Kommandos E und X im Direktmodus können folgende Fehler auftreten:
"Can't create in Direct Mode" ("Kann im Direktmodus nicht erzeugt werden")
Diese Meldung erschient, wenn versucht wird, auf eine Variable zuzugreifen, die nicht existiert (erzeugt wurde).
"Library Not Available in Direct Mode" ("Bibliothek im Direktmodus nicht verfügbar")
Wenn ein Blitz2-Befehl ausgeführt werden soll, der aus einer Bibliothek stammt, die nicht mit dem Programm geladen wurde, tritt dieser Fehler auf. Wenn ein Programm beispielsweise keine Strings verwendet, dann ist die Bibliothek, die die String-Befehle enthält, nicht Teil des Objektcodes. Infolgedessen können auch mit dem X-Kommando keine String-Befehle ausgeführt werden.
"Not enough Room in Direct Mode Buffer" ("Kein Platz mehr im Puffer für Direktmodus")
Dieser Fehler sollte eigentlich nie auftreten. Tritt er dennoch auf, so muß die Größe des Objekt-Puffers im Menü 'Compiler Options' erhöht werden.
"AT END OF BUFFER" ("Ende des Puffers erreicht")
Diese Meldung erschient, wenn versucht wird, mit dem F-Kommando über das Ende des Befehlspuffers hinaus zu gehen (s. Befehlspuffer).
|
|
|
|
|
|
|
