The class StdStreams in the package ch.ntb.inf.deep.host defines three output streams.

• log: is used for normal logging (e.g. successful compilation)
• vrb: for debugging purposes
• err: for errors

For development assertions should be extensively used. Make sure that they are enabled in eclipse with -ea as argument for the VM.

Debug output is very convenient during the development process. For efficiency reasons we use the following scheme: Every class has a constant debug of type boolean. If debug == true the compiler inserts write statements to StdStreams.vrb. To enable debug output you have to edit the source code (switch on debug). In the productive code their is no runtime penalty.

Für die Fehler-Ausgabe sollte die Klasse ErrorReporter im Package ch.ntb.inf.deep.host verwendet werden. Bei jeder Ausgabe eines Fehlers wird die statische Variable nofErrors inkrementiert. Der Launcher überprüft vor jedem Schritt diese Variable und bricht nach einem Fehler ab.

Der ErrorReporter benötigt die Datei ErrorMsg.txt im rsc Ordner. In dieser Datei werden die Fehler-Nummern mit ihren Beschreibungen und möglichen Lösungen eingetragen.

Die Methoden error(int errNr) und error(int errNr, String additonalInfo) greifen auf ErrorMsg.txt zu. Die Methoden suchen in der Datei die übergebene Fehlernummer, und geben diese mit der Beschreibung und falls vorhanden mit den möglichen Lösungen aus. Die zusätzlichen Informationen, wie z.B. Datei- und Zeilennummerangaben, werden hinten angefügt.

Im Weitern gibt es noch die Methode error(String errMsg), diese gibt die Fehlermeldung direkt aus, ohne dass eine Fehlernummer dafür definiert werden muss.

Der Launcher prüft vor jedem weiteren Schritt, ob kein Fehler aufgetreten ist. Was aber passiert, wenn innerhalb eines Schrittes (z.B. der Berechnung der Codegenerierung) ein Fehler auftritt, und zwar so, dass dieser Teil nicht mehr abgeschlossen werden kann? Das ist z.B. der Fall, wenn kein Register mehr alloziert werden kann. Unter Umständen ist die Aufruferkette sehr gross und wir wollen nur im äussersten Rufer, dem Launcher jeweils nofErrors prüfen.
Alle Methoden sollen so geschrieben werden, dass im Fehlerfall der ErrorReporter aufgerufen wird, aber die Methode trotzdem einen brauchbaren Rückgabewert liefert (also z.B. einfach das Register 0 oder den Node 0) und so die äusseren Methoden durchlaufen. U.U. können auch spezielle Objekte extra dafür geschaffen werden.
Es macht trotzdem Sinn daneben auch Assertions einzubauen. Diese sind dann nützlich, wenn wir als Entwickler den Fehler genau zu lokalisieren versuchen.