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 --~--~---------~--~----~------------~-------~--~----~ 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
