[antlr-interest] [v2 to v3][C++/C] throw C++ exception from parser/tree parser.

[Jim Idle]

That's all you need :) There are lots of examples in the stuff you have
found on how to override the default one. You can use the @members to
declare an instance of your error reporting classm then new and install
this object before parsing. You will want to install it in the lexer, the
parser and the tree parser.

Note that you should avoid having the lexer issue errors and try to code
for errors so you can report a good message:

STRING: '"' (~('"'|'\n'|'\r'))* ( '"'| /* call a method on your object to
issue 'missing quote' */) ;


Your error handler should have a number of methods that can handle the
data passed to displayRecognitionError(), a method that handles simple
lexer errors, a method that takes a start and end token (which may be
NULL), a method that takes a start and end (which may be null)
pCOMMON_TREE and anything else that is useful. Your method can then
extract text for the message from the input stream.

Also, code your error messages as objects/structs/something in a
collection and pass the desired error message as a symbol. The error
handler can then look up whether the message is a warning, error, or
fatal. A warning or error does not stop the next phase from running, a
fatal error does. Then a lexing error won't (possibly) stop the parser and
so on - you get the maximum information from one run by printing all the
errors at the end.

Note that your tree parser will likely call code (don't embed code in the
tree parser, just call your C++ objects with the desired information), to
issue semantic errors as hitting an AST formation error is most likely a
"Fatal Internal Compiler Error - panic!". In other words the
displayRecognitionError() is only part of the story - it only captures
syntax errors, but in the real world you want way more emphasis on
semantically detected errors, and you should code your parser to accept
bad syntax, then reject it as a semantic error.


Finally using symbolic representation of the message will allow you to
switch languages easily of course.

Hope that helps. It is a lot easier than I think you thought it was.


Jim


> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Ruslan Zasukhin
> Sent: Wednesday, September 07, 2011 12:13 PM
> To: antlr-interest at antlr.org
> Subject: Re: [antlr-interest] [v2 to v3][C++/C] throw C++ exception
> from parser/tree parser.
>
> On 9/7/11 7:36 PM, "Jim Idle" <jimi at temporal-wave.com> wrote:
>
> Hi Jim,
>
> > You remember that this is all open source, freely given right?
>
> Of course I do :-)
>
> And I have read sources of ANTLR 3.4, be sure.
> Btw, my congratulations and respect. Very high quality code.
>
> > Generally,
> > don't try and mix C++ things in with the C. Exceptions are almost
> > certainly not want you want for error reporting while parsing anyway.
>
> > As I said earlier, copy the existing routine and adapt it. It does as
> > many things as it can to show you how to access the information. I
> > can't provide a universal error message handler as there is no way to
> > know what information your particular parser will have available or
> > how you want the messages to look and so on. All your customer error
> > handler need do is call a C++ object that you provide and that object
> > can collect the errors so that you can print them out at the end etc.
> > The source code is right there and well commented :)
>
> Ahhaa,  I hope I have to hear you ...
> I will try say it now by own words to double check.
>
> * so we must implement own dsiplayError() -- this is clear.
>
> * we must NOT throw here any C++ exception.
>     Instead, we must just build some Err String and put it
>     e.g. Into our own Stack of such error strings
>
> * then we do
>
>    AST         =  parser->entryRule()
>    MyNodes = treePareser->entryRule()
>
> Zero exceptions here
> Then we just do
>
>     if( errCount > 0 )
>     {
>          stop  job
>          somehow report errors to user
>          for example
>
>         point ZZZ:
>          throw  myException(  ErrStack->getErrors() ;)
>     }
>
>
> Sounds right?
> Thank you, Jim for points.
>
> -----------------
> Well, only one more question come to mind.  :-)
>
> I have read that ANTLR3-C self build LIST OF exception objects.
> Is this true?
>
> If yes, then may be this is not needed? I mean override displayError()
> method?
>
> >> All your customer error handler need do is call a C++ object that
> you
> >> provide and that object can collect the errors so that you can print
> >> them out at the end etc.
>
> And we can "convert" that list into exception at point ZZZ in the above
> example?
>
>
> --
> Best regards,
>
> Ruslan Zasukhin
> VP Engineering and New Technology
> Paradigma Software, Inc
>
> Valentina - Joining Worlds of Information http://www.paradigmasoft.com
>
> [I feel the need: the need for speed]
>
>
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
> email-address