[DSL] Errorhandling #1374

malt-r · 2022-11-04T13:01:10Z

malt-r
Nov 4, 2022

Status Quo:
Es gibt keine durchgängige Strategie, um mit Fehlern umzugehen. "Umgang" bedeutet: Erkennen, Kommunizieren, Beheben, Reagieren. Meistens treten Fehler im DSLInterpreter und in den vorgeschalteten Analysen in SemanticAnalyzer zu spät auf, d. h. sie könnten früher erkannt und deutlich aussagekräftiger kommuniziert werden. Typechecking ist nicht implementiert. Die Reaktion auf einen Fehler besteht in den meisten Fällen im Werfen einer RuntimeException und im Beenden des Programms. Das ANTLR-Fehlerhandling ist aktuell auch nicht in das Gesamtsystem eingebunden.

Um die DSL wirklich produktiv einsetzen zu können, muss hierfür ein Konzept erarbeitet und umgesetzt werden. Dazu sollte analysiert werden, welche Fehlerarten es gibt, wie die zu behandeln und zu kommunizieren sind. Für einfache Syntax-Fehler sollten Synchronisationsgrenzen festgelegt werden, sodass ein einzelnes fehlendes Semikolon nicht eine Reihe an falschen und irreführenden Fehlermeldungen nach sich zieht. Darüber hinaus ist zu klären, welche Daten in welcher Form für die semantische Analyse gehalten werden müssen, um aussagekräftige Fehlermeldungen zu generieren.

Typinferenz und Typechecking wären wichtige Komponenten für die Fehlererkennung, sind allerdings auch alleine schon so groß, dass es ein kleines https://github.com/Programmiermethoden/Dungeon/labels/thesis Label bekommen und in #99 getrackt werden.

Der DSLInterpreter stellt eine Ausführungsumgebung für Funktionsdefinitionen dar. Hiermit tauchen alle in diesen Umgebungen "gängigen" Fehlerbilder auf (Zugriff auf nicht definierte oder in einem bestimmten Kontext nicht gültige Symbole, Zugriff auf null-Werte, Typfehler). Auch für diese Fehler muss ein Fehlerhandling definiert werden.

Ein weiterer Aspekt ist der Umgang mit dem ECS in der DSL. Das ECS ermöglicht das dynamische Hinzufügen und Entfernen von Components zu Entitys während der Programmlaufzeit. Per DSL-Konfiguration können DSL-Funktionen als Callback für Events aus dem Dungeon-Kontext definiert werden. D. h. Entitys werden als Parameter an DSL-Funktionen übergeben. Um in den Callback-Funktionen etwas mit den übergeben Entitys tun zu können, muss es möglich sein, auf die Components einer Entity zugreifen zu können. Dazu ist für jeden mögliche Component ein Property in der DSL-Abbildung des Entity-Datentypen vorgesehen. Falls jedoch das Entity-Objekt aus dem Dungeon-Kontext kein Component des entsprechenden Typs hat, ist der Rückgabewert dieser Property null. Greift das Program auf Symbole im Kontext des nicht vorhanden Components zu, stürzt das Programm ab. Hier könnte untersucht werden, inwiefern das Typsystem erweitert werden könnte, um diese Art der Fehler bereits vor der Programmausführung zu verhindern/erkennen/melden.