[antlr-interest] syntactic predicates and exceptions

Pete Gonzalez pgonzalez at bluel.com
Tue Nov 15 16:24:32 PST 2005


Don Caton wrote:
> 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 recently joined the mailing list, and I'd like to add a couple comments 
to last month's debate about unexceptional exceptions, since this issue has 
been an ongoing headache for my team using C# Antlr.

First, exceptions are slooooow in C#.  I am working on a real-world project 
that parses a text file containing relatively simple field/value pairs. 
We're using the lexer from Robin Debreuil's C# grammar example, which I 
assume is reasonably well designed.  On my 2.4Ghz Pentium PC, the input 
file (which is only 8671 lines / 228969 bytes) takes 840 ms to parse. 
This is pretty damn slow by yacc standards, but certainly usable.  However, 
when running in the debugger, I was shocked to find that the same parser 
takes 55.062 seconds, which is totally unacceptable, especially when you 
consider that the application will eventually have to parse thousands of 
files, not just a measly 8000 lines.  Why so slow?  Exceptions.

If you are a Java person applying Java thinking to C#, you'll probably say 
"well the C# compiler is broken -- those performance issues are a Microsoft 
flaw, not an Antlr problem."  I disagree.  In my experience, C# libraries 
simply don't throw hundreds of exceptions per second, and most exceptions 
correspond to real errors that end up being displayed in the GUI.  Since 
the Antlr web site very clearly advertises support for C#, I think this 
should warrant at least a gesture at compliance with the conventions for 
this platform.  In case there's any doubt, here's an unambiguous excerpt 
from a Microsoft "Best Practices" document:

http://tinyurl.com/aqzzh
 > Exceptions Are For Exceptional Circumstances
 >
 > Do not throw exceptions as a means of communicating between
 > components -- use events for that. Exceptions should not be
 > thrown in cases where completely expected results occur. For
 > example, a component that reads text files should not throw an
 > exception when it reaches the end of the file. This is a case
 > where an event would be appropriate. By limiting throwing
 > exceptions to exceptional cases, you will help developers to
 > debug their application rapidly by not having to wade through
 > numerous 'expected' exceptions.

This brings us to my second point:  trying to debug a application with 
Antlr calls.  In C#, NORMALLY in I would just set my debugger to break 
whenever an exception is thrown, and then hit F5 a few times until I reach 
the bug.  With Antlr, this is no longer possible.  Instead I have to turn 
off exception trapping, set a breakpoint somewhere near the problem but 
after the parser has finished, run to the breakpoint, then then re-enable 
exception trapping to catch the "real" error.  If Antlr is being called in 
a loop, this often requires hacking the code to add some kind of counter or 
if/then test around the breakpoint.  This is what Microsoft means when they 
say "wade through numerous expected exceptions", and it is a real headache.


In conclusion:  With regards to Java, we've discussed three possible 
choices (exceptions, no exceptions, or supporting both), and there have 
been good arguments in favor of each choice.  But for the C# version, I 
don't see how there can be any debate at all.

Cheers,
-Pete

NOTE: I use a spam filter, so if you e-mail me directly please put "antlr" 
in your subject line.  Thanks!



More information about the antlr-interest mailing list