Re: Bison error handling

[sgaurelius]

So, you re saying to do the first and add more errors as I find more errors.
Yeah, I guess this is the optimal.

Since it goes deep until finding the first error, it will print messages for
all errors or for the most basic one ? The latter is better I think.

Stratis


Hans Aberg wrote:
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> address@hidden http://lists.gnu.org/mailman/listinfo/help-bison
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Bison-error-handling-tp20964993p20976407.html
Sent from the Gnu - Bison - Help mailing list archive at Nabble.com.