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