Re: Error detection under Yacc

The question was asked: "What is the best way to detect an error under
Yacc?..."


There is no best way, you eventually need combined strategies. Yacc's
own error recovery is functionally reliable, but it can trash a lot of
code as it attempts to by pass errors recognized when input pattern do
not match any rule. It is not a bad idea to use 'error' in some of
your rules at a high level.


With the example specified, it may be useful for you to consider
'error productions,' if you have not already.


For example;


stmt : imp-stmt
            | cond-stmt


cond-stmt :
  IF cond THEN imp-stmt ELSE imp-stmt
      { /* normal siruation */
      emit(various nice things);
      }
  |
  IF cond imp-stmt ELSE imp-stmt
      { /* error production: missing THEN */
      diagnose(as warning or fatal);
      possiblyemit(various nice things);
      }
  |
  IF THEN imp-stmt ELSE imp-stmt
      { /* error production: missing conditional */
      diagnose(fatal);
      /* emit nothing */
      yyerror("Conditional expression missing");
      yyerrorok;
      }




Also, for the sake of completeness, you may wish to distinguish
detecting an error from responding to an error. You can detect errors
with error productions; but not necessarily invoke error recovery in
each such production. Just as it will be optional to invoke 'yyerrok'
or to engage something aggressive like 'yyclearin' within responses to
errors.


Generally the best way to handle errors is to start with a fairly
complete list of what you will do about errors, and then guide the
grammar into those behaviors. But honestly we usually do not start
there; handling errors is like a second thought (or an inconvenience
to us). So when you do get to it, you at first think you can do it
with a few things here, a few things there. That will not work, you
need an overall plan.


Usually folks try to keep processing to get as much from the compiler
for the user as possible in each invocation. But it can be real
difficult to keep going in the midst of chaos. Wherever possible try
to prevent YACC from a free fall scan for three successive parsible
tokens once error recovery starts. This can reject a lot of code, and
cause incomprehendible diagnostics in subsequent code dependent on the
material skipped.


Error productions are one way to take matters into your own hands and
either tolerate and repair poor syntax or reject it without loosing
control.


With data definition syntax errors, it can be useful to try to
instantiate some kind of symbol (like a universal-error-type item of
the name specified). This will allow subsequent referencing code to at
least parse.


Hope that helps.


Robert Rayhawk
RKRayhawk@aol.com

Return to the comp.compilers page.
Search the comp.compilers archives again.