Erkanntes, aber nicht akzeptiertes Token |
Top Previous Next |
Meldungen > Erkanntes, aber nicht akzeptiertes Token
Falls die Ausführung eines TETRA-Programms durch einen Fehler abgebrochen wurde, kann es einen Hinweis auf ein erkanntes aber nicht akzeptiertes Token in der Log-Fenster geben. Vermutlich trat im Interpreter ein Fehler auf, bevor das erwartete Token akzeptiert werden konnte. Oder es wurde versehentlich eine Return-Anweisung vor die Ermittlung des nächsten Tokens gesetzt.
Beispiel:
ID {{ return true; }} NUMBER
Hier wird nach dem ersten Bezeichner ID eine Zahl NUMBER erwartet. NUMBER kann aber nicht erkannt werden, da die Produktion zuvor mit return verlassen wird.
Möglich ist auch, dass ist die Benutzung eines globalen Scanners für reguläre Ausdrücke aktiviert ist, obwohl zwei Token dieses Scanners miteinander in Konflikt stehen können.
Bestehe beispielsweise eine kleine Tabelle aus den beiden Spalten Version und Preis eines Produkts und seien diese definiert als
Version = \d\.\d\d Price = \d\d?\.\d\d
d.h. eine Preisangabe kann eine oder zwei Vorkommastellen haben, eine Versionsangabe stets aber nur eine. Der Inhalt der Tabelle kann nun mit der Regel geparst werden:
Table = ( Version Price )*
Wird nun ein globaler Scanner benutzt, so ist nicht klar, ob eine Zahl mit nur einer Vorkommastelle durch Price oder durch Version erkannt wird. Befindet sich die Zahl in der ersten Spalte, erfolgt die Erkennung dennoch möglicherweise durch Price und das Parsen wird mit der Fehlermeldung abgebrochen, dass Price zwar passt, aber nicht akzeptiert wird. Bei Verwendung lokaler Scanner ergibt sich hingegen keinerlei Problem, da je nachdem, ob sich die Zahl in der ersten oder zweiten Tabellenspalte befindet, jeweils nur auf eine Versionsnummer oder auf einen Preis getestet wird.
|
Diese Seite gehört zur TextTransformer Dokumentation |
Home Inhalt English |