Hi Jim,
Thanks for your reply. We finally figure out that large number of expecting is actually -1, which is EOF. I guess this would rule out the possibility of a bug in antlr, if we don't speak of the appropriateness of the message. In the use case I mentioned in my last email, I would think start(Rule2), start(Rule3) and ; all should be the expected tokens, instead of EOF. Do you think if there is anything antlr can do to improve the error messages to make them more relevant? Or should I improve my grammar to get more appropriate error messages, and how? Also I can see when the displayRecognitionError() checks the recognizer type, it only considers either parser or tree parser, why is lexer not considered here? I can see that a lexer error is considered a No Via Alt parser exception, but there is still lexer error report from antlr, where can I find the lexer error report code? Or how can I intercept the lexer error like I do with the parser error report? Many thanks! Linlin From: Jim Idle [mailto:[email protected]] Sent: 09 June 2009 17:25 To: Xie, Linlin Cc: [email protected]; Fitt, Andrew; Hamid, Nusrat Subject: Re: problem in displayRecognitionError() in antlr2baserecognizer.c Xie, Linlin wrote: Hello Jim and all, I wonder if there is any bug in antlr setting the "expecting" member variable of struct "ANTLR3_EXCEPTION". The following is what I find out while assigning my own error processing function to antlr's recognizer's reportError function pointer: For my grammar definition like: "Query: Rule1 Rule2? Rule3? ; EOF" And for my test case that has a malformed syntax, which matches Rule1, but the rest doesn't match either Rule2 or Rule3, through debugging, I find that the parser then tries to match with ";", of course it doesn't match ";" again, then it tries to report error and recover. In the antlr's error reporting (I did it by copying the content of displayRecognitionError() to my own error processing function), the "expecting" variable should point to the position of ";" as that's what it tries to match. But it shows that the expecting is a very large number that can't possibly be within the range of the Hi - the routines in the runtime are just examples. You are expected to make a copy of them and install your own routines. Note that the expecting member of the token is not always a valid token number. For instance you have to check it for being -1, which means it was expecting EOF, which is probably what it is expecting in your grammar above right? if (ex->expecting == ANTLR3_TOKEN_EOF) { Also, for some exception types, expecting is not a valid field. The default routines should show you that as not all exceptions access expecting. Finally, for some exceptions, you don't get a token number, but a bit set, from which you must extract the set of tokens that coudl have matched. This is a possibility here because your possibilities are start(Rule2) & start(Rule3) & ';'. In the code that processes ANTLR3_MISMATCHED_SET_EXCEPTION, you can see how to deal with the bit set. So, if your expecting code is not -1, then it is a bitmap in all likelihood. vector "TokenNames", however as C doesn't have exception handlings, the print out is "null", if without looking carefully, it seems to be no problem at all. But what I'm trying to do in my own function is to read out the error information from antlr exception and output it into standout output in C++, that's how an exception is thrown in C++ that leads me to the problem. I did some probing of the antlr code, and think it could be a bug when antlr sets the "expecting" variable in case of such an error. Also I find that the exception variable has a nextexception pointer which points to another exception variable The nextException isn't used by the default error reporting, I just included it in case anyone thought it useful. Jim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en -~----------~----~----~----~------~----~------~--~---
List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
