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