Let’s build a compiler #12 Variable bereits definiert – Compilerbau ANTLR Tutorial deutsch HD

Let’s build a compiler #12 Variable bereits definiert – Compilerbau ANTLR Tutorial deutsch HD


Willkommen zurück zu “Let’s build a compiler”. In der letzten Folge haben wir in unserem Visitor eine “UndeclaredVariableException” eingebaut, die uns bei einem Zugriff auf eine nicht definierte Variable genau sagt was Sache ist. Und zwar inklusive Zeilennummer und Spaltennummer aus unser Datei in der der Zugriff erfolgt. In dieser Folge werden wir unsere Exceptions so ausweiten, dass es auch für andere Formen von Fehlern taugt. Außerdem werden wir eine Exception für doppelt definierte Variablen hinzufügen und uns ansehen was eigentlich passiert wenn wir unseren Compiler ohne Test mit einem fehlerhaften Quelltext füttern. Wir haben hier auch noch diese “varDeclaration”, da habe ich eben gesagt: Da ist es natürlich gut wenn die Variable nicht deklariert ist, weil wir wollen sie ja nicht zweimal definieren, aber genau das ist eben auch noch ein Punkt: Sie sollte nicht schon existieren. Wenn die Variable schon existiert sollten wir auch einen Fehler ausgeben. Also erweitern wir wieder unsere Spezifikation: Nehmen mal wieder diesen Testfall hier als Template und dann sagen wir hier: Wir haben “int x” und dann haben wir in der nächsten Zeile nochmal “int x”. Na, nehmen wir hier lieber den “System.lineSperator”. Das ist jetzt ein Fehler und da sollten wir jetzt sagen nicht “throwsUndeclaredVariableException”, sondern: “throwsVariableAlreadyDefinedException”… …”ifVariable”… oder… “whenDefiningAlreadyDefinedVariable”. Dann müssen wir natürlich hier unsere “expectedException” auch noch anpassen, also ist es nicht mehr “undeclaredVariable”, sondern “VariableAlreadyDefined”. Auch unsere “expectedExceptionsMessageRegExp” wird sich ein wenig ändern: Und zwar ist der Fehler jetzt hier in der 2. Zeile und dann an Position 1, 2, 3, 4. Und da haben wir jetzt: Variable already defined. Vielleicht noch ein Doppelpunkt, dann macht der Satz mehr Sinn. Auch diese Exception müssen wir jetzt anlegen. Wieder in unserem source directory und zu unser anderen Exception und jetzt brauchen wir hier natürlich ganz ähnliche Dinge wie wir auch in unser UndeclaredVariableException hatten, also die “line” und die “column” und deswegen macht es Sinn wir nehmen da eine gemeinsame Superklasse. Also erstellen wir hier noch einmal eine neue Klasse und dann nennen wir die hier “CompileException” als eine Superklasse für alle Exceptions die während unseres Kompiliervorgangs auftreten. Und die bekommt jetzt einige der Features, die bis jetzt in der “UndeclaredVariableException” vorkamen. Nämlich sie leitet von der “RuntimeException” ab, dann bekommt sie hier auch “line” und “column” und die beiden Felder machen wir dann “protected” damit wir in den ableitenden Klassen darauf zugreifen können. Und dann werden wir auch den Constructor hier noch einfügen. Das jetzt natürlich nicht unbedingt ein varName-Token, deswegen nenne ich die Variable auch nur “token”, weil wir wissen nicht was das für ein Token ist und den “varName” können wir hier natürlich auch nicht verwenden. Der Name muss noch angepasst werden und dann ist gut. Dann wird jetzt hier die UndeclaredVariableException nicht mehr von der RuntimeException ableiten, sondern von unser CompileException und wir werden hier das “line” und das “column” rauschmeißen und das hier auch rausschmeißen und stattdessen an unseren super-Konstruktor delegieren. So, damit ist unsere Klasse schonmal ein bißchen kürzer geworden und in unser VariableAlreadyDefinedException sieht das jetzt so ähnlich aus, da leiten wir ebenfalls von unser CompileException ab, fügen einen Constructor ein, der das “variableToken” bekommt und an die Superklasse delegiert und der hat auch einen “variableName” und auch hier brauchen wir dann noch eine getMessage-Methode. Die sieht der hier ein wenig ähnlich, deswegen klaue ich die mal hier, nur dass es jetzt nicht heißt “undeclared variable” sondern “variable already defined”. So, hier fehlt mir noch das “import”, Strg+Shift+O, dann kriegt ihr die auto-imports, nehmen wir das v4-Token und dann müssen wir diese Exception natürlich auch noch werfen. Dafür gehen wir also wieder in unseren Visitor und gehen dann zu “visitVarDeclaration” und da schauen wir jetzt vorher einmal nach: “if (variables.containsKey)” und jetzt von unserem Kontext: “varName.getText()”. Also wenn diese Variable schon definiert ist, dann schmeißen wir eine VariableAlreadyDefinedException. Das “new” ist ganz wichtig, nicht vergessen und übergeben “ctx.varName”. So, dann führen wir unseren Test mal wieder aus und sehen: Ich habe etwas vergessen. Nämlich hier: Da ist hier nur null angekommen, das habe ich also offensichtlich mal nicht richtig initialisiert und da könnt ihr schonmal wieder sehen, dass so eine Spezifikation in Form eines automatisieren Tests sehr hilfreich ist, denn wenn man solche Kleinigkeiten vergisst, dann findet man die sehr schnell. Also gehen wir zurück zu unser VariableAlreadyDefinedException und schreiben dann hier auch noch dass der “varName” bitte von dem variableNameToken aus initialisert wird. Dann führen wir den Test nochmal aus und diesmal hat es geklappt, Alle Tests sind in Ordnung, auch unser neuer “throwsVariableAlreadyDefinedException”-Test. So, dann möchte ich euch nochmal zeigen wie das ganze aussieht, wenn wir unseren Compiler sozusagen “normal” ausführen mit Hilfe von unser Mainklasse und ein Fehler auftritt. Also werden wir unsere code.demo-Datei anpassen und hier jetzt mal reinschreiben: “println(x)”. Und dann werden wir unsere “Main” einmal ausführen. Dann schauen wir uns an was dabei rauskommt. Wir sehen hier jetzt also eine Exception in main, mit einer UndeclaredVariableException, in Zeile 1, an Position 8, da haben wir jetzt eine “undeclared variable” “x”. Jetzt können wir daraus sehr gut ablesen was wir falsch gemacht haben. In dieser Folge haben wir gelernt wie wir Exceptions im Visitor für unterschiedliche Fehlertypen verwenden können. Eine gemeinsame Superklasse für alle Kompilierungsfehler kann die Zeile und Spalte des Fehlers speichern und spezifische Fehlerdetails können in ableitenden Klassen untergebracht werden. Habt ihr Fragen oder Wünsche? Schreibt es mir in die Kommentare! Lasst mir außerdem einen Daumen da wenn euch das Video gefallen hat und ein Abo damit ihr keine neue Folge verpasst. Vielen Dank an Gadarol, der mir für die Aufnahmen sein Studio zur Verfügung stellt. Und euch vielen Dank für eure Aufmerksamkeit. Mein Name ist yankee, ich hoffe es hat euch Spaß gemacht, Bis zum nächsten Mal, wenn es wieder heißt: “Let’s build a compiler”.

3 thoughts on “Let’s build a compiler #12 Variable bereits definiert – Compilerbau ANTLR Tutorial deutsch HD”

  1. Hey yankee, ich habe mir mittlerweile schon einige deiner bisher 12 Videos angeschaut (natürlich ohne auch nur ein Wort zu verstehen) und muss zu dem Schluss kommen, dass du einen richtig guten Job machst. Alleine die Einblendung zu Beginn, was du an welcher Stelle in dem Video behandelst, finde ich sehr gut und auch einfallsreich. Du erklärst alles sehr ruhig und gelassen und man bekommt auch als Laie den Eindruck, dass du weißt was du tust 😉
    Insofern kann ich dich nur ermuntern weiterzumachen, auch wenn ich für meinen Teil leider zu dem Schluss kommen muss, dass deine Thematik für den Bereich Youtube etwas zu speziell angelegt sein dürfte. Die breite Masse wird nunmal leider nicht sehr viel damit anfangen können, was du da treibst. Aber dennoch muss ich sagen das du das sehr gut machst 🙂
    LG

  2. Sehr gute Tutorialreihe! Ich beschäftige mich als Hobby mit der Programmierung (hauptsächlich Java, aber auch andere Sprachen) und habe bisher keine gute und kostenlose Einführung in das Thema gefunden. Vorallem kein einziges gutes Tutorial für Java und auch nichts auf deutsch.
    Vielen Dank für die Videos. Es ist alles sehr gut und verständlich erklärt und ich kann die Reihe jedem empfehlen, der sich mit dem Thema auseinander setzen möchte.

    Die Einzige Sache die ich noch anmerken möchte: Ich denke nicht, dass auch jemand mit keiner Java-Erfahrung das Tutorial gut genug versteht und das dann auch mit einer anderen Sprache anwenden kann (Ich meine, dass du das am Anfang im ersten Video gesagt hast, falls nicht nehme ich die Aussage zurück.). (Ich kann übrigends nur jedem die Podcasts von "Thomas Slawig"(Prof. an der UNI Kiel) über Java ans Herz legen. Man lernt dabei die Basics + simple GUI Programmierung, muss aber natürlich ein wenig logisches Verständnis oder Grundlegende Kenntnisse einer anderen Sprache mitbringen.

    Ich fände es außerdem an manchen Stellen hilfreich, wenn du den Eclipse workspace jeder Folge (oder auch nur den Endgültigen) als Download anbieten könntest. Ich arbeite nicht parallel an einer eigenen Version, sondern versuche eigentlich immer die Theorie von etwas zu verstehen und dann aus dem Kopf eine eigene Version davon zu erstellen, bzw. das Gelernte dann anzuwenden. Dabei wäre es aber nebenbei hilfreich, wenn ich hin und wieder nachschauen kann, wie du an welcher Stelle etwas gemacht hast, ohne alle Videos nochmal durchschauen zu müssen.

    Ich würde mir übrigends noch ein Tutorial über Interpreter wünschen.

Leave a Reply

Your email address will not be published. Required fields are marked *