[antlr-interest] syntactic predicates and exceptions

Don Caton dcaton at shorelinesoftware.com
Tue Oct 18 09:03:04 PDT 2005


Ter: 

Exceptions should be used for just that: exceptions.  A rule that fails to
match is not an exceptional condition, it is an expected condition and as
such, should be handled with normal flow control constructs.

IMO, efficiency should be the overriding concern, not whether any given
piece of code is "ugly" or not.  "Ugly" is subjective anyhow, and the end
user couldn't care less what the code looks like.  The inside of your coffee
maker is probably not terribly attractive either, or else the case would not
be opaque.  As long as the code is decently formatted and readable and can
be debugged without making your eyes bleed, that should be sufficient.  

Putting if's throughout the code isn't going to slow anything down, you're
talking about a handful of cpu instructions.  Contrast that to throwing a
single exception that requires thousands of instructions to execute, then
multiply that by the number of exceptions thrown in any non-trivial grammar.

I don't think you should use exceptions for error conditions either.  Errors
in parsing are an expected condition, not an exceptional condition.  IMO,
the only time Antlr should throw an exception is when something truly
exceptional happens (out of memory, unexpected end of stream or something
else that would never occur under normal conditions).

Don

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org 
> [mailto:antlr-interest-bounces at antlr.org] On Behalf Of Terence Parr
> Sent: Tuesday, October 18, 2005 11:32 AM
> To: ANTLR Interest
> Subject: [antlr-interest] syntactic predicates and exceptions
> 
> Howdy,
> 
> Many people have complained about the fact that ANTLR uses 
> exceptions  
> for backtracking and it's slow in many languages and many grammars.   
> For v3 I was thinking of changing to be return values and 
> lots of IF checks everywhere...ugly but fast.
> 
> Then i realized last night that it's not so easy.  We use 
> exceptions for throwing exceptions right?  All the support 
> code for match, matchAny, blah blah throws exceptions, which 
> would trigger rewinding the backtracking predicate in v2.  
> How can we use exceptions for error conditions and not for 
> guessing?  Do people propose that we duplicate the support 
> library code or put IFs everywhere in the support code, 
> perhaps slowing all cases down?
> 
> Perhaps looking at javacc output (which avoids exceptions for  
> backtracking I think) would be useful.  I don't like a mixed model.   
> Remember, normal case you want exceptions and backtracking 
> case you don't.  Pretty messy support code if you ask me.  
> Easy to say "get rid of exceptions", but now when it comes to 
> doing it I don't see a clean solution.  I also hate the idea 
> that even when not backtracking you'll see code like this 
> everywhere (ugly and slower):
> 
> if ( !match(ID) ) {code inserted to clean up; return false;} 
> // indicate error if guessing
> 
> instead of the current
> 
> match(ID);
> 
> Note: java can use a try/finally for the cleanup code but 
> other languages will need perhaps a goto or to duplicate 
> cleanup code at
> *all* exit sites...ick.
> 
> Ideas for implementing backtracking without exceptions?
> 
> Ter
> 




More information about the antlr-interest mailing list