[antlr-interest] DIY AST error recovery problem

Ross Bencina rbencina at iprimus.com.au
Tue May 6 01:49:08 PDT 2003


Ric Klaren wrote:
> > At the moment, if the ident rule fails, then ident() returns an empty
(null)
> > auto_ptr and the a-> expression in name() crashes. I could explicitly
check
> > return values for null before using them, but right now I don't
understand
> > the problem enough to know which return values to check - I would prefer
not
> > to have to check every rule's return value for NULL, although I have a
> > sinking feeling that's what I will have to do.
>
> I'm assuming you are using the default error handling mechanism?

Yes, although until Monty's RTFM response I didn't even know that there was
anything other than the default error handling.

> If the
> error over a IDENT is handled at the end of the ident rule by the default
> error handler it will return a null pointer.

That's right.

> You might get away with turning of the default (or the complete)
> errorhandlers for the ident rule. That way the parse error is escalated to
> the name rule and the action for with the list will not be performed.
Since
> ident's error is handled at the end of the name rule.
>
> ident returns [ std::auto_ptr<IdentifierNode> result ]
>         options { defaultErrorHandler = false; }
> : .......
>
> Depends a bit on other rules if this works 100%. Look at the generated
code
> for ident to get a feel for the effect of this.

Ok, will do. Right now this error handling stuff is a mysterious and
orthogonal dimension which I had entirely failed to consider - which is
disturbing me to say the least. I have a 1000 line .g file with C++ actions
like the above, and absolutely no handling for these kinds of errors -
working out a strategy to make the whole file error-safe seems like a
daunting task at this stage. Presumably every rule in the entire grammar
could throw a parsing exception and crash various parts of my AST generation
code - perhaps the best strategy is to turn off all error handlers, that way
the worst thing that can happen is the parser will barf, then I can slowly
re-introduce my own (or the default) exception handling at places where I
know it is safe to do so - at the statement level is one place that comes to
mind. I still don't understand how to invoke ANTLR's error recovery code if
I insert my own catch blocks.

Best wishes

Ross.


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




More information about the antlr-interest mailing list