[antlr-interest] BUG? lookahed and exception handler do not mix well

[Ric Klaren]

pganelin wrote:
> Summary: 
> I was trying to wrap my own exception from semantic action into  
> RecognitionException and I found the following problem. I do not 
> understand how to resolve it properly. An example of
> grammar file showing the issue is attached. For me it looks like a 
> design bug for lookahead exception handling.

What happens if you add custom error handlers? Your example looks too 
fishy to make anything from for me at first glance. Where you talk of 
lookahead you seem to mean guessing mode/syntactic predicates? Or are 
you actually using a semantic predicate?

> Description:
> 
> ANTLT generates the following exception handler for lookahead and the 
> resulting code does not compile.
> 
> 
>        catch ( IOException ex ) {
>            if (inputState.guessing==0) {
>                throw new RecognitionException ("IO exception");
>            } else {
>                throw ex ;
>            }
>        }

Error output would be helpfull. What antlr version is this actually? Is 
this a lexer?

> Without lookahead it would be just
> 
>        catch ( IOException ex ) {
>                throw new RecognitionException ("IO exception");
>        }
> and it is exactly what I need.
> 
> I understand that idea of lookahead it to propagate exception and deal 
> with them later, but it should propagate only ANTLR exception. While 
> ANTLR is doing lookahead it does not call actions and so it cannot 
> generate user defined exception. As a result catch clause is not 
> required to propagate it because the exception can not be raised in the 
> first place.

Init actions are called even during guessing mode. I'm not 100% sure 
from the top of my head but an IOException should not come out of the 
lexer. Anycase.. I have no clue wether you're running into a real bug, 
or that you are running into antlr behaviour that's 'normal' in a 
twisted sense.

Your example does not help at all in clarifying things (at least it only 
confused me more ;) ). Cut things down to a simple .g file that's not 
too contrived and that clearly demonstrates the problem.

Cheers,

Ric