{"id":6977,"date":"2024-09-06T14:00:16","date_gmt":"2024-09-06T11:00:16","guid":{"rendered":"https:\/\/new.intechcore.com\/?p=6977"},"modified":"2025-12-01T14:15:22","modified_gmt":"2025-12-01T11:15:22","slug":"entwicklung-einer-eigenen-programmiersprache-in-javaantlr-fehlerdiagnose","status":"publish","type":"post","link":"https:\/\/intechcore.com\/en\/entwicklung-einer-eigenen-programmiersprache-in-javaantlr-fehlerdiagnose\/","title":{"rendered":"Developing your own programming language in Java+ANTLR: diagnostics of errors"},"content":{"rendered":"

This is the second article in the series\u00a0\u201cDeveloping your own programming language in Java\u201d,\u00a0first article can be read\u00a0here<\/a>.<\/p>\n

At the current stage,\u00a0we have an interpreter capable of executing the commands of our language.\u00a0However,\u00a0this is not enough if we want to check the code for errors and display them in a clear way to the user.\u00a0In this article we will consider adding error diagnostics to the language.\u00a0Conducting error analysis in your own programming language is an important step in language development.\u00a0Using powerful tools,\u00a0such as\u00a0ANTLR<\/a>,\u00a0allows you to implement rather efficient code analysis tools in a short time that will help you to detect potential problems in a program at early stages of development,\u00a0which helps to improve software quality and increase developer’s productivity.<\/p>\n

Classification of errors<\/h2>\n

There are different types of errors,\u00a0but in general they can be divided into three categories:\u00a0syntax<\/strong>,\u00a0semantic<\/strong>\u00a0and\u00a0runtime errors<\/strong>.<\/p>\n

Syntax errors<\/strong>\u00a0occur due to violation of the syntax rules of a particular programming language.\u00a0Syntax rules define how statements and expressions in code should be organized.<\/p>\n

Example of a syntax error\u00a0(missing closing quote):<\/p>\n

println<\/span>(“<\/span>Hello, <\/span>World!)<\/span><\/div>\n
var<\/span> a =<\/span> 1<\/span> +<\/span> 2<\/span> *<\/span> 3<\/span><\/div>\n

One could expect the variable\u00a0a<\/code>\u00a0to be equal to 9,\u00a0but in fact it will be equal to 7.\u00a0This happens because the multiplication operator has higher precedence than the addition operator.\u00a0A semantic error can usually be discovered during debugging or extensive testing of the program.<\/p>\n

Runtime errors<\/strong>,\u00a0also known as Exceptions,\u00a0occur during program execution.\u00a0Such errors can occur due to incorrect data entry,\u00a0attempting to access a non-existent file,\u00a0and in many other scenarios.\u00a0Some runtime errors can be handled in a program,\u00a0but if this is not done,\u00a0the program usually crash.<\/p>\n

In addition to errors,\u00a0it is also important to detect potential problems or non-obvious situations that are not errors in the strict sense,\u00a0but may lead to undesirable consequences.\u00a0For example,\u00a0it could be an unused variable,\u00a0use of deprecated functions,\u00a0or a meaningless operation.\u00a0In all such cases,\u00a0warnings<\/em>\u00a0can be shown to the user.<\/p>\n

JimpleBaseVisitor<\/h2>\n

To identify errors and warnings,\u00a0we need the abstract class\u00a0JimpleBaseVisitor<\/code>\u00a0(generated by ANTLR),\u00a0familiar to us from the first article,\u00a0which by default implements the\u00a0JimleVisitor<\/code>\u00a0interface.\u00a0It allows you to traverse the AST tree\u00a0(Abstract Syntax Tree<\/em>),\u00a0and based on the analysis of its nodes we will decide upon the error,\u00a0warning or normal part of the code.\u00a0In essence,\u00a0diagnosing errors is almost no different from interpreting code,\u00a0except when we need to perform I\/O or access external resources.\u00a0For example,\u00a0if a console output command is executed,\u00a0then our task is to check whether the data type is passed as an argument is valid,\u00a0without directly outputting to the console.<\/p>\n

Let’s create the\u00a0JimpleDiagnosticTool<\/code>\u00a0class,\u00a0which inherits\u00a0JimleBaseVisitor<\/code>\u00a0and encapsulates all the logic of finding and storing errors:<\/p>\n

class<\/span> JimpleDiagnosticTool<\/span> extends<\/span> JimpleBaseVisitor<\/span><<\/span>ValidationInfo<\/span>><\/span> {
private<\/span> Set<\/span><<\/span>Issue<\/span>><\/span> issues =<\/span> new<\/span> LinkedHashSet<\/span><><\/span>();<\/span>
}<\/p>\n

record<\/span> Issue<\/span>(IssueType<\/span> type<\/span>,<\/span> String<\/span> message<\/span>,<\/span> int<\/span> lineNumber<\/span>,<\/span> int<\/span> lineOffset<\/span>,<\/span> String<\/span> details<\/span>) {}<\/div>\n

This class contains a list of type\u00a0Issue<\/code>,\u00a0which represents information about a specific error.<\/p>\n

It is known that each method of a given class must return a value of a certain type.\u00a0In our case,\u00a0we will return information about the type of node in the tree\u00a0–\u00a0ValidationInfo<\/code>.\u00a0This class also contains information about the possible value,\u00a0this will help us identify some semantic or runtime errors.<\/p>\n

record<\/span> ValidationInfo<\/span>(ValidationType<\/span> type<\/span>,<\/span> Object<\/span> value<\/span>) {}<\/p>\n

enum<\/span> ValidationType<\/span> {
\/**<\/span>
<\/span>*<\/span> <\/span>Expression <\/span>returns <\/span>nothing.<\/span>
<\/span>*\/<\/span>
VOID<\/span>,<\/span><\/p>\n

\/**<\/span>
<\/span>*<\/span> <\/span>Expression <\/span>is <\/span>String<\/span>
<\/span>*\/<\/span>
STRING<\/span>,<\/span><\/p>\n

\/**<\/span>
<\/span>*<\/span> <\/span>Expression <\/span>is <\/span>double<\/span>
<\/span>*\/<\/span>
DOUBLE<\/span>,<\/span><\/p>\n

\/**<\/span>
<\/span>*<\/span> <\/span>Expression <\/span>is <\/span>long<\/span>
<\/span>*\/<\/span>
NUMBER<\/span>,<\/span><\/p>\n

\/**<\/span>
<\/span>*<\/span> <\/span>Expression <\/span>is <\/span>boolean<\/span>
<\/span>*\/<\/span>
BOOL<\/span>,<\/span><\/p>\n

\/**<\/span>
<\/span>*<\/span> <\/span>Expression <\/span>contains <\/span>error <\/span>and <\/span>analysing <\/span>in <\/span>another <\/span>context <\/span>no <\/span>makes <\/span>sense.<\/span>
<\/span>*\/<\/span>
SKIP<\/span>,<\/span><\/p>\n

\/**<\/span>
<\/span>*<\/span> <\/span>When <\/span>object <\/span>can <\/span>be <\/span>any <\/span>type. <\/span>Used <\/span>only <\/span>in <\/span>Check <\/span>function <\/span>definition <\/span>mode.<\/span>
<\/span>*\/<\/span>
ANY<\/span>,<\/span><\/p>\n

\/**<\/span>
<\/span>*<\/span> <\/span>Tree <\/span>part <\/span>is <\/span>function <\/span>declaration<\/span>
<\/span>*\/<\/span>
FUNCTION_DEFINITION<\/span>
}<\/div>\n

You should pay attention to the value of\u00a0ValidationType.SKIP<\/code>.\u00a0It will be used if an error has been found and already registered in a part of the tree,\u00a0and further analysis of this tree node does not make sense.\u00a0For example,\u00a0if one argument in a sum expression contains an error,\u00a0then the second argument of the expression will not be analyzed.<\/p>\n

ValidationInfo<\/span> checkBinaryOperatorCommon<\/span>(ParseTree<\/span> leftExp<\/span>,<\/span> ParseTree<\/span> rightExp<\/span>,<\/span> Token<\/span> operator<\/span>) {
ValidationInfo<\/span> left =<\/span> visit<\/span>(leftExp);<\/span>
if<\/span> (left.<\/span>isSkip<\/span>()) {
return<\/span> ValidationInfo<\/span>.<\/span>SKIP<\/span>;<\/span>
}
ValidationInfo<\/span> right =<\/span> visit<\/span>(rightExp);<\/span>
if<\/span> (right.<\/span>isSkip<\/span>()) {
return<\/span> ValidationInfo<\/span>.<\/span>SKIP<\/span>;<\/span>
}
\/\/<\/span> <\/span>code <\/span>omitted<\/span>
}<\/div>\n

Listeners vs Visitors<\/h2>\n

Before moving on,\u00a0let’s take a look at another ANTLR-generated interface\u00a0JimpleListener<\/code>\u00a0(pattern\u00a0Observer<\/a>),\u00a0which can also be used if we need traverse the AST tree.\u00a0What is the difference between them?\u00a0The biggest difference between these mechanisms is that listener methods are always called by ANTLR on a per-node basis,\u00a0whereas visitor methods must bypass their child elements with explicit calls.\u00a0And if the programmer does not call\u00a0visit()<\/code>\u00a0on child nodes,\u00a0then these nodes are not visited,\u00a0i.e.\u00a0we have the ability to control tree traversal.\u00a0For example,\u00a0in our implementation,\u00a0the function body is first visited once in its entirety\u00a0(mode\u00a0checkFuncDefinition==true<\/code>)\u00a0to detect errors in the entire function\u00a0(all if and else blocks),\u00a0and several times with specific argument values:<\/p>\n

@<\/span>Override<\/span>
ValidationInfo<\/span> visitIfStatement<\/span>(IfStatementContext<\/span> ctx<\/span>) {
\/\/<\/span> <\/span>calc <\/span>expression <\/span>in <\/span>“if” <\/span>condition<\/span>
ValidationInfo<\/span> condition =<\/span> visit<\/span>(ctx.<\/span>expression<\/span>());<\/span><\/p>\n

if<\/span> (checkFuncDefinition) {
visit<\/span>(ctx.<\/span>statement<\/span>());<\/span>
\/\/<\/span> <\/span>as <\/span>it’s <\/span>just <\/span>function <\/span>definition <\/span>check, <\/span>check <\/span>else <\/span>statement <\/span>as <\/span>well<\/span>
JimpleParser<\/span>.<\/span>ElseStatementContext<\/span> elseStatement =<\/span> ctx.<\/span>elseStatement<\/span>();<\/span>
if<\/span> (elseStatement !=<\/span> null<\/span>) {
visit<\/span>(elseStatement);<\/span>
}
return<\/span> ValidationInfo<\/span>.<\/span>VOID<\/span>;<\/span>
}<\/p>\n

\/\/<\/span> <\/span>it’s <\/span>not <\/span>check <\/span>function <\/span>definition, <\/span>it’s <\/span>checking <\/span>of <\/span>certain <\/span>function <\/span>call<\/span>
if<\/span> (condition.<\/span>isBool<\/span>() &&<\/span> condition.<\/span>hasValue<\/span>()) {
if<\/span> (condition.<\/span>asBoolean<\/span>()) {
visit<\/span>(ctx.<\/span>statement<\/span>());<\/span>
} else<\/span> {
JimpleParser<\/span>.<\/span>ElseStatementContext<\/span> elseStatement =<\/span> ctx.<\/span>elseStatement<\/span>();<\/span>
if<\/span> (elseStatement !=<\/span> null<\/span>) {
visit<\/span>(elseStatement);<\/span>
}
}
}<\/p>\n

return<\/span> ValidationInfo<\/span>.<\/span>VOID<\/span>;<\/span>
}<\/div>\n

The Visitor pattern works very well if we need to map a specific value for each tree node.\u00a0This is exactly what we need.<\/p>\n

Catching syntactic errors<\/h2>\n

In order to find some syntax errors in the code,\u00a0we need to implement the\u00a0ANTLRErrorListener<\/code>\u00a0interface.\u00a0This interface contains four methods that will be called\u00a0(by the parser and\/or lexer)\u00a0in case of an error or undefined behavior:<\/p>\n

interface<\/span> ANTLRErrorListener<\/span> {
void<\/span> syntaxError<\/span>(Recognizer<\/span><<\/span>?<\/span>,<\/span> ?<\/span>><\/span> recognizer<\/span>,<\/span> Object<\/span> offendingSymbol<\/span>,<\/span> int<\/span> line<\/span>,<\/span> int<\/span> charPositionInLine<\/span>,<\/span> String<\/span> msg<\/span>,<\/span> RecognitionException<\/span> e<\/span>);<\/span>
void<\/span> reportAmbiguity<\/span>(Parser<\/span> recognizer<\/span>,<\/span> DFA<\/span> dfa<\/span>,<\/span> int<\/span> startIndex<\/span>,<\/span> int<\/span> stopIndex<\/span>,<\/span> boolean<\/span> exact<\/span>,<\/span> BitSet<\/span> ambigAlts<\/span>,<\/span> ATNConfigSet<\/span> configs<\/span>);<\/span>
void<\/span> reportAttemptingFullContext<\/span>(Parser<\/span> recognizer<\/span>,<\/span> DFA<\/span> dfa<\/span>,<\/span> int<\/span> startIndex<\/span>,<\/span> int<\/span> stopIndex<\/span>,<\/span> BitSet<\/span> conflictingAlts<\/span>,<\/span> ATNConfigSet<\/span> configs<\/span>);<\/span>
void<\/span> reportContextSensitivity<\/span>(Parser<\/span> recognizer<\/span>,<\/span> DFA<\/span> dfa<\/span>,<\/span> int<\/span> startIndex<\/span>,<\/span> int<\/span> stopIndex<\/span>,<\/span> int<\/span> prediction<\/span>,<\/span> ATNConfigSet<\/span> configs<\/span>);<\/span>
} <\/div>\n

The name of the first method\u00a0(syntaxError<\/code>)\u00a0speaks for itself;\u00a0it will be called in case of a syntax error.\u00a0The implementation is quite simple:\u00a0we need to convert the error information into an object of type\u00a0Issue<\/code>\u00a0and add it to the list of errors:<\/p>\n

@<\/span>Override<\/span>
void<\/span> syntaxError<\/span>(Recognizer<\/span><<\/span>?<\/span>,<\/span> ?<\/span>><\/span> recognizer<\/span>,<\/span> Object<\/span> offendingSymbol<\/span>,<\/span> int<\/span> line<\/span>,<\/span> int<\/span> charPositionInLine<\/span>,<\/span> String<\/span> msg<\/span>,<\/span> RecognitionException<\/span> e<\/span>) {
int<\/span> offset =<\/span> charPositionInLine +<\/span> 1<\/span>;<\/span>
issues.<\/span>add<\/span>(new<\/span> Issue<\/span>(IssueType<\/span>.<\/span>ERROR<\/span>,<\/span> msg,<\/span> line,<\/span> offset,<\/span> makeDetails<\/span>(line,<\/span> offset)));<\/span>
}<\/div>\n

The remaining three methods can be ignored.\u00a0ANTLR also implements this interface itself\u00a0(see class\u00a0ConsoleErrorListener<\/code>)\u00a0and sends errors to the\u00a0standard error stream<\/code>\u00a0(System.err).\u00a0To disable it and other standard handlers,\u00a0we need to call the\u00a0removeErrorListeners<\/code>\u00a0method on the parser and lexer:<\/p>\n

\/\/<\/span> <\/span>remove <\/span>default <\/span>error <\/span>handlers<\/span>
lexer.<\/span>removeErrorListeners<\/span>();<\/span>
parser.<\/span>removeErrorListeners<\/span>();<\/span><\/div>\n

Another type of syntax error is based on the rules of a particular language.\u00a0For example,\u00a0in our language,\u00a0a function is identified by its name and number of arguments.\u00a0When the analyzer encounters a function call,\u00a0it checks whether a function with the same name and number of arguments exists.\u00a0If not,\u00a0then it throws an error.\u00a0To do this,\u00a0we need to override the\u00a0visitFunctionCall<\/code>\u00a0method:<\/p>\n

@<\/span>Override<\/span>
ValidationInfo<\/span> visitFunctionCall<\/span>(FunctionCallContext<\/span> ctx<\/span>) {
String<\/span> funName =<\/span> ctx.<\/span>IDENTIFIER<\/span>().<\/span>getText<\/span>();<\/span>
int<\/span> argumentsCount =<\/span> ctx.<\/span>expression<\/span>().<\/span>size<\/span>();<\/span>
var<\/span> funSignature =<\/span> new<\/span> FunctionSignature<\/span>(funName,<\/span> argumentsCount,<\/span> ctx.<\/span>getParent<\/span>());<\/span>
\/\/<\/span> <\/span>find <\/span>a <\/span>function <\/span>in <\/span>the <\/span>context <\/span>by <\/span>signature <\/span>(<\/span>name+number <\/span>of <\/span>arguments)<\/span>
var<\/span> handler =<\/span> context.<\/span>getFunction<\/span>(funSignature);<\/span><\/p>\n

if<\/span> (handler ==<\/span> null<\/span>) {
addIssue<\/span>(IssueType<\/span>.<\/span>ERROR<\/span>,<\/span> ctx.<\/span>start,<\/span> “<\/span>Function <\/span>with <\/span>such <\/span>signature <\/span>not <\/span>found: <\/span>“<\/span> +<\/span> funName);<\/span>
return<\/span> ValidationInfo<\/span>.<\/span>SKIP<\/span>;<\/span>
}<\/p>\n

\/\/<\/span> <\/span>code <\/span>omitted<\/span>
}<\/div>\n

Let’s check the\u00a0if<\/code>\u00a0construct.\u00a0Jimple requires that the expression in the\u00a0if<\/code>\u00a0condition is of\u00a0boolean<\/code>\u00a0type:<\/p>\n

@<\/span>Override<\/span>
ValidationInfo<\/span> visitIfStatement<\/span>(IfStatementContext<\/span> ctx<\/span>) {
\/\/<\/span> <\/span>visit <\/span>expression<\/span>
ValidationInfo<\/span> condition =<\/span> visit<\/span>(ctx.<\/span>expression<\/span>());<\/span>
\/\/<\/span> <\/span>skip <\/span>if <\/span>expression <\/span>contains <\/span>error<\/span>
if<\/span> (condition.<\/span>isSkip<\/span>()) {
return<\/span> ValidationInfo<\/span>.<\/span>SKIP<\/span>;<\/span>
}<\/p>\n

if<\/span> (!<\/span>condition.<\/span>isBool<\/span>()) {
addIssue<\/span>(IssueType<\/span>.<\/span>WARNING<\/span>,<\/span> ctx.<\/span>expression<\/span>().<\/span>start,<\/span> “<\/span>The <\/span>\\”<\/span>if<\/span>\\”<\/span> <\/span>condition <\/span>must <\/span>be <\/span>of <\/span>boolean <\/span>type <\/span>only. <\/span>But <\/span>found: <\/span>“<\/span> +<\/span> condition.<\/span>type<\/span>());<\/span>
}<\/p>\n

\/\/<\/span> <\/span>code <\/span>omitted<\/span>
}<\/div>\n

The attentive reader will notice that in this case we added a warning,\u00a0not an error.\u00a0This is done due to the fact that our language is dynamic,\u00a0and we don’t always know the exact information about the type of the expression.<\/p>\n

Identify semantic errors<\/h2>\n

As mentioned earlier,\u00a0semantic errors are difficult to find and can often be found only during debugging or testing the program.\u00a0However,\u00a0some of them can be identified at the compilation stage.\u00a0For example,\u00a0if we know that the function\u00a0X<\/code>\u00a0always returns\u00a00<\/code>,\u00a0then we can show a warning if a division expression uses this function as a divisor.\u00a0Division by zero is usually considered a semantic error,\u00a0since division by zero makes no sense in mathematics.<\/p>\n

An example of error detection\u00a0“Division by zero<\/a>“:\u00a0triggered when an expression is used as a divisor,\u00a0which always returns the value\u00a00<\/code>:<\/p>\n

ValidationInfo<\/span> checkBinaryOperatorForNumeric<\/span>(ValidationInfo<\/span> left<\/span>,<\/span> ValidationInfo<\/span> right<\/span>,<\/span> Token<\/span> operator<\/span>) {
if<\/span> (operator.<\/span>getType<\/span>() ==<\/span> JimpleParser<\/span>.<\/span>SLASH<\/span> &&<\/span> right.<\/span>hasValue<\/span>() &&<\/span> ((Number<\/span>) right.<\/span>value<\/span>()).<\/span>longValue<\/span>() ==<\/span> 0<\/span>) {
\/\/<\/span> <\/span>if <\/span>we <\/span>have <\/span>value <\/span>of <\/span>right’s <\/span>part <\/span>of <\/span>division <\/span>expression <\/span>and <\/span>it’s <\/span>zero<\/span>
addIssue<\/span>(IssueType<\/span>.<\/span>WARNING<\/span>,<\/span> operator,<\/span> “<\/span>Division <\/span>by <\/span>zero<\/span>“<\/span>);<\/span>
}<\/p>\n

\/\/<\/span> <\/span>code <\/span>omitted<\/span>
}<\/div>\n

Runtime errors<\/h2>\n

Runtime errors are also difficult or even impossible to detect at the compilation\/interpretation stage.\u00a0However,\u00a0some such errors can still be identified.\u00a0For example,\u00a0if a function calls itself\u00a0(either directly or through another function),\u00a0this may result in a stack overflow error\u00a0(StackOverflow<\/a>).\u00a0The first thing we need to do is to declare a list\u00a0(Set)\u00a0where we will store the functions that are in the process of being called at the moment.\u00a0The check itself can\u00a0(and should)\u00a0be placed in the\u00a0handleFuncInternal<\/strong>\u00a0method of processing the function call.\u00a0At the beginning of this method,\u00a0we check whether the current\u00a0FunctionDefinitionContext<\/strong>\u00a0(function declaration context)\u00a0is in the list of already called functions,\u00a0and if that is the case,\u00a0we log a Warning and interrupt further processing of the function.\u00a0If not,\u00a0then we add the current context to our list,\u00a0and the rest of the logic follows.\u00a0When exiting handleFuncInternal,\u00a0you need to remove the current function context from the list.\u00a0Here it should be noted that in this case we not only identified a potential StackOverflow,\u00a0but also got rid of the same error when diagnosing error,\u00a0namely when looping the handleFuncInternal method.<\/p>\n

Set<\/span><<\/span>FunctionDefinitionContext<\/span>><\/span> calledFuncs =<\/span> new<\/span> HashSet<\/span><><\/span>();<\/span><\/p>\n

ValidationInfo<\/span> handleFuncInternal<\/span>(List<\/span><<\/span>String<\/span>><\/span> parameters<\/span>,<\/span> List<\/span><<\/span>Object<\/span>><\/span> arguments<\/span>,<\/span> FunctionDefinitionContext<\/span> ctx<\/span>) {
if<\/span> (calledFuncs.<\/span>contains<\/span>(ctx)) {
addIssue<\/span>(IssueType<\/span>.<\/span>WARNING<\/span>,<\/span> ctx.<\/span>name,<\/span> String<\/span>.<\/span>format<\/span>(“<\/span>Recursive <\/span>call <\/span>of <\/span>function <\/span>‘%s’ <\/span>can <\/span>lead <\/span>to <\/span>StackOverflow<\/span>“<\/span>,<\/span> ctx.<\/span>name.<\/span>getText<\/span>()));<\/span>
return<\/span> ValidationInfo<\/span>.<\/span>SKIP<\/span>;<\/span>
}
calledFuncs.<\/span>add<\/span>(ctx);<\/span><\/p>\n

\/\/<\/span> <\/span>other <\/span>checkings<\/span><\/p>\n

calledFuncs.<\/span>remove<\/span>(ctx);<\/span><\/p>\n

\/\/<\/span> <\/span>return <\/span>resulting <\/span>ValidationInfo<\/span>
}<\/div>\n

Control\/data-flow analysis<\/h2>\n

For a deeper study of program code,\u00a0optimization and identification of complex errors,\u00a0Control-flow analysis<\/strong>\u00a0and\u00a0Data-flow analysis<\/strong>\u00a0are also used.<\/p>\n

Control flow analysis is focused on understanding which parts of a program are executed depending on various conditions and control structures such as conditional\u00a0(if-else)\u00a0statements,\u00a0loops,\u00a0and branches.\u00a0It allows you to identify the program execution paths and detect potential errors associated with incorrect flow control logic.\u00a0For example,\u00a0unreachable code or potential program hangpoints.<\/p>\n

Data flow analysis,\u00a0on the other hand,\u00a0focuses on how data is distributed and used within a program.\u00a0It helps identify potential data problems such as the use of uninitialized variables,\u00a0data dependencies,\u00a0and possible memory leaks.\u00a0Data flow analysis can also detect errors associated with incorrect data operations,\u00a0such as the use of incorrect types or incorrect\u00a0(meaningless)\u00a0calculations.<\/p>\n

Summary<\/h2>\n

In this article,\u00a0we have examined the process of adding error and warning diagnostics to your programming language.\u00a0We have learned what does the ANTLR provides out of the box for logging syntax errors.\u00a0We have alos implemented a handling of some errors and potential problems during program execution.<\/p>\n

The entire interpreter source code can be viewed here<\/a>.<\/p>\n

Links<\/h2>\n

Semantic errors<\/strong>\u00a0occur when a program is compiled and even executed,\u00a0but the result is different from what was expected.\u00a0This type of error is the most difficult.\u00a0Semantic errors can be caused by the programmer’s misunderstanding of the language or the task at hand.\u00a0For example,\u00a0if a programmer has a poor understanding of\u00a0operator precedence<\/a>,\u00a0then he can write the following code:<\/p>\n