[antlr-interest] How to throw an exception for all parsing errors?

Paul Bouché paul.bouche at apertio.com
Fri Apr 3 08:17:58 PDT 2009


Jim Idle schrieb:
> Johannes Luber wrote:
>> Peter C. Chapin schrieb:
>>   
>>> Hello!
>>>
>>> I'm working with the C# target. I'm writing test cases for my parser. I
>>> try to parse a collection of input files to verify that they all parse as
>>> expected (later I'll probably also verify that erronous input fails to
>>> parse, but that's for another day). I'm trying to use NUnit to manage the
>>> test cases.
>>>
>>> It is convenient for the parser to throw an exception at the first problem
>>> since NUnit will catch unhandled exceptions and display their tracebacks,
>>> etc. The ANTLR book talks about how to do this. As I understand it I have
>>> to provide my own mismatch() and recoverFromMismatchedSet() methods. I
>>> also have to provide a @rulecatch block that catches RecognitionException
>>> and rethrows it. The book shows this in Java, but the C# version is
>>> basically the same (I replaced IntStream with IIntStream).
>>>
>>> It almost seems to work. However while playing with my test cases I
>>> noticed that under certain circumstances no exception is thrown and the
>>> parser returns normally... even though an error message is written to
>>> standard error. In the case in question I have an extra ';' where 'END' is
>>> supposed to be. I get the following message on standard error:
>>>
>>> extraneous input ';' expecting END
>>>
>>> The message is quite reasonable. The problem is that NUnit thinks the test
>>> succeeded. NUnit's GUI console does display the error message on the
>>> 'Console Error' tab but the test still shows green. This is a problem for
>>> me because when I run my tests I want to be able to just look at the green
>>> lights and be happy. If I also have to investigate other tabs I will
>>> likely forget and I might overlook a problem.
>>>
>>> So my question is simply: is there a way to get even this kind of error to
>>> thrown an exception as well? I could also solve my problem if there was
>>> some way to learn from the result returned by the parser if the parse was
>>> completely successful or not. Did ANTLR execute any kind of recovery? If I
>>> could check for that I could fail the test and be happy as well.
>>>
>>> Peter
>>>     
>>
>> This seems to be a bug in ANTLR as such behavior doesn't fit my
>> expectations, too.
> No, it is not a bug, it is the defined behavior as you can see from 
> the runtime. A missing token is manufactured and no exception is 
> thrown, an extraneous token is deleted and no exception is thrown. 
> This is part of error recovery.
>
>
> Check the docs for the runtime functions like getMissingToken and so on.
>
> However, while there is no exception, it does increment the error 
> counts, so all you need do is after the invocation of the parser in 
> your test, check for a non zero error count and throw an 're' or 
> something similar.
>
Seems like you forgot to override a method. If you want an exception 
upon first error you must make sure that the recovery mechanism does not 
start.
In ANTLR v3.1.x the mismatch() method was renamed to 
recoverFromMismatchedToken() - imo that should be clearer in the release 
notes, i.e. a BIG FAT warning because it is so different from the book.


Does that help?
BR,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20090403/6a745a03/attachment.html 


More information about the antlr-interest mailing list