[antlr-interest] C Runtime Error Handling Problems

Jim Idle jimi at temporal-wave.com
Wed Jan 28 07:50:32 PST 2009


Bot Tiger wrote:
> Hello ANTLR community,
>
> I have been testing out the error reporting capabilities of the C 
> runtime and have run into some difficulties trying to get a Line Number.
>
>
> Using the calculator example from the 5 minute intro to ANTLR, I have 
> tried to use the default error handler.
> However, upon trying to detect an EOF token, it segfaults, so I have 
> attempted to override the default error handlers at

I think that this was just an error trying to make a string out of it, 
which is fixed in the latest snapshot I think. If it isn't, then I shall 
have to look in to this some more.
>
> pParser->rec->reportError
> pParser->rec->recover
>
> pLexer->rec->reportError
> pLexer->rec->recover
>
>
> Entering an incomplete expression such as "1+2+" results in an error 
> of ANTLR3_EARLY_EXIT_EXCEPTION.
>
> Unfortunately, in antlr3baserecognizer.c, all it does is:
> ANTLR3_FPRINTF(stderr, " : missing elements...\n");
>
> All my attempts to get a string offset from anywhere have failed.
Just look at what the other exceptions do. It probably prints this 
string because it thinks the location information is already printed. As 
it says in the comments this routine is meant to be a guideline, as I 
cannot know what you need an error message routine to do in advance.
>
> Here are a list of my attempts and why it fails.
>
> ========================================
> recognizer->state->exception->charPositionInLine      
> --- returns -1
This indicates EOF or some other token that is not actually in the input 
stream and is thefore telling you not to make a string out of the token 
directly.
>
> theToken    = (pANTLR3_COMMON_TOKEN)(recognizer->state->exception->token);
> ttext        = theToken->toString(theToken);
> --- returns a gibberish string
It isn't returning a string, it returns a pANTLR3_STRING, from which you 
can get a null terminated string to printf with. HOwever, I think that 
the toString() onan EOF token was the abort that I just fixed this weekend.
>
> theToken->getCharPositionInLine(theToken);
> --- also returns -1
See above.
>
> recognizer->state->tokenNames[exception->expecting]
> --- exception->expecting is always 0, and the string returned is 
> always "<invalid>"
This means that it could not determine  what should have come next, or 
that the expecting field is actaully an expecting set and not a single 
token. The set is contained in the exception.
>
>
> recognizer->state->tokenStartLine
> --- always returns 0
>
> recognizer->state->tokenStartCharPositionInLine
> --- always returns 0
>
> recognizer->state->tokenStartCharIndex
> --- always returns 0
>
It isn't a real token, then it has no position in the token stream.
>
> (pANTLR3_COMMON_TOKEN)exception->token->....
> --- same problems as tokens above
>
See above.
> recognizer->state->token->....
> --- same problem as tokens above
see above.
>
> (pANTLR3_COMMON_TOKEN)recognizer->getCurrentInputSymbol(recognizer, 
> parser->tstream->istream)
> --- same problems as the tokens above
See above.
>
>
>
> As you can see I've exhausted almost every combination I can think of, 
> and I am just wondering if none of the offset indexes are implemented.
It is all there, copy the code for other exceptions basically. Also try 
the latests snapshots and see if the EOF error has gone away or not. If 
not then I will add a bug.

Jim


More information about the antlr-interest mailing list