Re: Bison error handling

[Hans Aberg]

On 12 Dec 2008, at 00:39, sgaurelius wrote:

> if I want to define, exactly what messages or actions bison should  
> do when
> an error occurs, what should I do. From what I 've searched, either  
> I can do
>
> 1) what is says in
> http://www.slac.stanford.edu/comp/unix/gnu-info/bison_9.html
> or
> 2) what is says in
> http://www.ibm.com/developerworks/linux/library/l-flexbison.html? 
> ca=dgr-lnxw16FlexAndBisonErrorHand
>
> The problem with the first is, that I have to strictly define all the
> possible errors and messages for the whole grammar, whereas I would  
> prefer a
> more abstract solution.
> The problem with 2) is that, it doesn't really defines exactly the  
> messages,
> only it enriches them. So bison produces better messages, without the
> programmer to define what it'll print or do, when an error occurs.

The 'error' token works in a similar way to the 'catch' of C++; the  
'throw' is the error itself, syntactic, or generated by an action  
(see manual).

So you put in as many of them as you like: more if you want to fine- 
tune. So, if "file" is the sentence symbol, one might start with say:
file:
    file_contents {}
  |               {}
  | error {
      declaration_context = false;
      YYABORT;
    }
;
if say one just wants to abort and reset a lexer global variable.

Then refine, and put in more 'error' tokens as you go along. When the  
Bison encounters a generated error, it unwinds the parser stack until  
the first generated 'error' token state is encountered.

As you see they put the 'error' token close to other tokens. The LALR 
(1) that Bison uses compacts states so am error may not be issued  
immediately, after some reductions. Therefore, error recovery may not  
be so good. Using LR(1) without such state compaction having that  
flaw might be better.

  Hans