Now, when designing a full-fledged language, errors can be reported to the user in many different ways — red underlines in the editor, as “problems” in the debugging tab, or through the console. We want to have a central place to collect and report issues, which is why we need the error handler.
issues
The issues property contains a list of all problems pertaining to the user’s code. Whenever the tokeniser, parser, or interpreter come across issues, they add them to this list. Furthermore, a non-empty issue list while abort the compilation process before the AST is interpreted.
reportAll
This function will report all the issues in the issues list, through the IssueReporter. The IssueReporter specifies how the issues are reported. Do note that this method does not clear the issues list — you'll need to compile the program again.
Issue
An Issue represents an actual error or warning in the program.
consoleString
The consoleString getter returns a String representation of the error, for the purpose of being printed to the console.
IssueTitle
There are different types of errors — syntax errors, module errors, null errors, etc. But each type of error has subtypes too. A syntax error can be due to an unexpected token or an unterminated literal, or a missing semicolon. We could use an enum for the various subtypes, but then could you do the following?