[antlr-interest] AntLR C# target exceptions problem

[Sam Harwell]

I make my IntelliSense parser stop after N exceptions (default 20) via
an OperationCanceledException to prevent major performance problems with
very large files in the IDE, since the file is often syntactically
incorrect while it is being edited and it's reparsed often.

 

Sam

 

From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Jim Idle
Sent: Monday, April 13, 2009 10:18 AM
Cc: antlr-interest at antlr.org
Subject: Re: [antlr-interest] AntLR C# target exceptions problem

 

Jan Newger wrote: 

Johannes Luber wrote:
  

		Johannes Luber wrote:
		      

			Does putting a breakpoint into the catch block
work? Otherwise the menu
			        

		for exceptions offers the options to break when an
exception is thrown and
		if an exception is caught. Furthermore, did you add a
messagebox call or
		console print to check if the catch block is actually
executed (in release
		mode)? Otherwise I can't check things out myself, as my
development machine
		has a display problem and is thus unusable right now.
		Putting a breakpoint into the catch block doesn't work.
If you look at
		the code I posted, there actually is a messagebox call,
which is never
		executed (debug or release mode doesn't matter).
		 
		I noticed however, that when a NoViableAltException is
thrown from my
		generated parser, that the parser itself catches it,
calls ReportError
		then Recover and ultimately returns silently from this
method (start
		symbol of my grammar). So in fact the exception is
swallowed by the
		parser itself. Is this "by design"? I just didn't expect
this kind of
		behavior, because it seems to be quite different from
the java runtime
		approach. What would be the solution? Should I override
the ReportError
		method in my parser and rethrow the exception?
		      

	I've never used the error recovery process myself, but I think
that you have to overwrite 3 methods. If ReportError() is one of them I
don't know but
<http://www.antlr.org/wiki/display/ANTLR3/Error+reporting+and+recovery>
<http://www.antlr.org/wiki/display/ANTLR3/Error+reporting+and+recovery>
has some insights. Don't forget to use .NET capitalisation instead the
Java one.
	 
	    

 
Thanks for your quick response, Johannes. Actually, I don't want to
override the error reporting mechanism, I just want the runtime to throw
the respective exceptions when the input is malformed (just in the same
way the java runtime does it).
Is the behavior I previously described considered a bug or is this "by
design"? It seems odd to me that exceptions are swallowed within the
parser itself. So even if I where to replace the error reporting
mechanism, I would change the error message of an exception which never
reaches my code in the first place. IMHO this is ether a serious bug or
I'm doing something incredibly stupid here.
 
  


I think that the rules will catch the exception which is why you won't
see it higher up. If you override the error reporting mechanism, you can
then throw your own exception type that isn't caught by the rules. You
can also use the exception clause (well, you can with Java and I think
that you can with C#) on a rule by rule basis in your grammar and once
again throw something not caught in the rule chain. So either implement
displayRecognitionError and just throw something:


@members
{
  displayRecognitionError(String[] tokenNames, RecognitionException e) {

    throw new Tantrum(e); // or somethign similar
  }
}

or:

rule
 : X Y Z
 ;
catch [RecongitionException re] {

   throw new Tantrum(re);  // Or something similar
}


I think that the Wiki has more information on making parsers stop at the
first error, though I have never really understood why this would be
useful myself ;-)

Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20090413/e31efe13/attachment.html