[antlr-interest] Error handling using parallel instances of a C-target parser

[Jim Idle]

Read through this, which shows you how to get back through the chain.

http://markmail.org/message/taakrcaujhqk7uy4

You can use the CTX macro to get the overall context pointer and store that somewhere accessible by you too.

Jim

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Johannes Goller
> Sent: Monday, May 17, 2010 12:03 AM
> To: antlr-interest at antlr.org
> Subject: Re: [antlr-interest] Error handling using parallel instances
> of a C-target parser
> 
> Thank you, Jim, for the quick reply.
> I read through all the posts I could find related to
> displayRecognitionError, but I still have one question:
> Inside my new definition of displayRecongitionError, how do I access
> the members of my parser defined
> through @apifuncs?
> 
> displayRecongitionError has two arguments: the recognizer and the
> token names. The recognizer appears
> to contain a "super" pointer that leads to the ANTLR3_PARSER struct.
> That also has a "super" member, but
> I don't understand where it points to.
> How can I get to the data structure, whose members are defined by
> @apifuncs?
> 
> 
> Many thanks,
> johannes.
> 
> 
> Use antlr.markmail.org and look for displayRecognitionError. Remember
> that if
> you have parallel threads, you will want the error collections to be
> thread
> instances, not global members. Therefore you add them as context
> members
> @apifuncs etc.
> 
> http://antlr.markmail.org/search/?q=apifuncs#
> 
> http://antlr.markmail.org/search/?q=displayRecognitionError+C
> 
> Jim
> 
> -----Original Message----- From: antl... at antlr.org
> [mailto:antlr-interest- boun... at antlr.org] On Behalf Of Johannes
> Goller Sent: Sunday, May 09, 2010 11:05 PM To: antl... at antlr.org
> Subject: [antlr-interest] Error handling using parallel instances of a
> C-target parser
> 
> Hello,
> 
> I am working with a C-target parser, and I have multiple instances of
> the parser running in parallel.
> 
> Now I would like to stop the parser from printing error messages to
> stderr. Instead, I would like each instance of the parser to collect
> the error messages in a list of strings, so that the caller can access
> the complete list of error messages after the parser finished and
> decide what to do about them.
> 
> >From an example I found here: http://groups.google.com/group/il-antlr-
> interest/browse_thread/thread/80ec25032e9af7a8?pli=1 I understand how
> members of the parser instance can be defined using @parser::context
> and @parser::apifuncs, and that works very well. So, let's say I
> defined a member
> 
> error_list_t *error_list
> 
> which points to some kind of dynamic list structure, and assume there
> is a global function
> 
> add_to_error_list(error_list_t *, const char* msg)
> 
> which can be used to add a new message to the list.
> 
> Now I wonder how can the error handling methods of ANTLR be modified
> to add error messages to the list rather than printing them to stderr.
> 
> Looking at various sources on the internet, it seems there is a
> function emitErrorMessage() which is called whenever an error occurs.
> Taking that as a starting point, I have the following questions:
> 
> (1) Is that the right function to override? Or is there a better one?
> (2) How exactly do I have to specifiy the override in the ANTLR
> grammar? (3) How can I access the current instance of the parser from
> inside the error handling function? Remember that error_list must be a
> member of the parser, rather than a global object, because I have
> several parsers operating in parallel.
> 
> Many thanks for any help.
> 
> johannes.
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
> email-address
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
> email-address