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
 4. while ($a < 10) {
 5.     $a += 3
 6.     $b += 2
 8.     if ($b < 5) {
 9.         $b = 
10.     }
11. }
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

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?

  • Is it meaningful to continue on after you get a syntax warning?
    – user40980
    Nov 13, 2015 at 15:17
  • @MichaelT Well, if it so happens that the faulty code doesn't run anyway, your algorithm can still execute without problems, and you can repair it after the execution. I figure it could be very useful for debugging, but I'm worried about possible abuse/misuse of this 'feature'.
    – Mirac7
    Nov 13, 2015 at 19:15
  • Or you could continue on and generate completely incorrect values. Which returns to "is it meaningful to continue?" What is the worst thing that can happen if you get an incorrect answer and warnings (that are ignored)? If this is a minor inconvenience - that's one thing. If it is controlling life support equipment or the message on the front page of an important site, that's another. What are the repercussions of the code "working"?
    – user40980
    Nov 13, 2015 at 19:18
  • 2
    I'm voting to reopen/migrate this question because it appears to deserve a proper answer, but possibly from an audience with stronger expertise with compiler and language design. Also, it might be the case it is too broad, but this is not for us (i.e. it is only proper for people with that expertise) to decide.
    – rwong
    Dec 19, 2015 at 17:39
  • 1
    I've never found "fail late" behaviour anything but really angering (a complete compile with compile time errors is like a free [if only partially complete] test suite). Fail late code has a much higher chance of getting into production and being hard to diagnose Dec 19, 2015 at 19:35

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.