How to approach syntax errors when developing a lexical analyser?

Question

I am writing an interpreted domain-specific language for my application. Each statement is parsed and executed as soon as lexical analyser decides that the end of statement is reached. It's handling one token at a time and makes recursive calls evaluating expressions and reducing current token stack.

It intuitively makes sense for the parser to first check for syntax errors before actually interpreting and executing the code, but I was thinking that it might be another way of handling this.

What if syntax were checked just before the code in question needs to be executed? This means that actually flagging code for invalid syntax wouldn't happen until the problematic code is actually reached. This also means that if the code is faulty, but shouldn't be executed, we can raise non-fatal warnings instead of errors to notify the programmer, but let the code execute anyway.

Take for instance this code:

 1. new $a = 2
 2. new $b = 3
 3.
 4. while ($a < 10) {
 5.     $a += 3
 6.     $b += 2
 7.
 8.     if ($b < 5) {
 9.         $b = 
10.     }
11. }
12.
13. printout($a)
14. printout($b)

As one line is typed in after another, standard interpreter would execute first two lines, but error would be raised on line 9, as no value is being assigned to $b and the process would terminate due to fatal error.

This approach outputs:

SyntaxError at line 9: $b = ; - Expression expected
Process terminated with exit code 1

If the parser checks syntax one line at the time, expression $b < 5 never evaluates to true, and faulty code never executes. Its syntax is still checked and raises a warning flag.

This approach outputs:

SyntaxWarning at line 9: $b = ; - Expression expected
SyntaxWarning at line 9: $b = ; - Expression expected
SyntaxWarning at line 9: $b = ; - Expression expected
11
9

If the faulty code needs to be executed, SyntaxErrors would be raised unconditionally. The only difference would be when the code doesn't execute. Language is written for graphics generation/manipulation software.

Should I be including syntax warnings in my interpreter or should I let faulty code always terminate the execution? What factors should influence this decision?

Answer 1

There's really only one factor to consider, which is how safe it is for your program to ABEND or produce incomplete or invalid results.

One end of the spectrum is that it's just an annoyance. People run their programs and discover that they didn't get the results they expected and then have to track down the cause, maybe having to dig through megabytes of data that have a syntax error message buried in it. There's no real harm done, but it could pose a personal safety problem if your users are psychotic and know your home address. :-)

The other is that it causes real damage, which is where you want to take an all-or-nothing approach. If the domain for your language involves a process of brewing chemicals where the finished product is inert but one of the intermediate products is toxic, an ABEND at the wrong point could leave a vat of toxic sludge to be dealt with. In a case like that, you want to be as sure as possible that the program has a good chance of finishing before you start running it.

Doing one or the other shouldn't have a huge impact on your development. A parser that produces a parse tree can simply return some indication that there was an error, which makes the decision to proceed or stop easy. Those that execute the statements as it finds them would need a switch to prevent that. To prevent execution of an invalid program, you'd then need to parse it twice: once with execution disabled and, if the parser had no complaints about the input, again with it enabled.

My own take on this is that if you can provide a way for the people using your language to validate their programs without executing them, you should do so. Manipulating graphics isn't safety-critical, but the people who have to build and integrate systems using your language will want to do that. The process of getting from development to production is increasingly automated, and providing a programmatic way to throw up a roadblock when there's a detectable problem is nothing but a positive.