[antlr-interest] Error reporting with ANTLR tree grammar

[Terence Parr]

Also see book where I talk about errors (I think it's a free chapter).

http://media.pragprog.com/titles/tpantlr/errors.pdf

oh crap. just a sample not whole chapter. oh well. last page will get you started on "paraphrase" concept.

Ter

On Nov 24, 2010, at 4:47 PM, Michael Matera wrote:

> Hi Arthur,
> 
> I have a parser where I've spruced up the error messages to make more 
> sense to my users.  I overrode the (Java) methods:
> 
> String getErrorHeader(RecognitionException e)
> String getErrorMessage(RecognitionException e, String[] tokenNames)
> 
> In getErrorHeader() I look at the exception and determine how I want to 
> display where the error came from.  The RecognitionException has a 
> 'token' member (which may be null) and a line member.  If it has a token 
> then you may be able to get a filename from 
> token.getInputStream().getSourceName().
> 
> In getErrorMessage() I try to figure out why the parse error happened 
> and tell my users the human meaning of the error.  Mostly this means 
> doing something like this:
> 
> if (e instanceof UnwantedTokenException) {
>  ...
> } else if (e instanceof NoViableAltException) {
>  ...
> } else if (e instanceof FailedPredicateException) {
>  ...
> }
> 
> Pay special attention to FailedPredicateException because that exception 
> stores the string of the failed predicate.  You can match it to say what 
> it really means.  But be aware if multiple predicates were excluded you 
> may not get the one that's "really" the problem.
> 
> One other tip:  Because my parser rules structurally resemble my 
> language (I have a rule for 'if' and 'for' and 'while', etc).  I can use 
> the stack trace inside the exception to see what rule I was in.  That 
> way I can tell my user something like "Unexpected end to a 'for' 
> statement," when they forgot to close the conditions section.
> 
> Hope this helps.
> 
> Cheers
> ./m
> 
> 
> Here's a snipet from my parser:
> 
>> @members {
>> 
>> @Override
>> public String getErrorHeader(RecognitionException e) {
>>  ...
>> }
>> 
>> @Override
>> public String getErrorMessage(RecognitionException e, String[] tokenNames) {
>>  return ErrorReporting.getParseErrorMessage(this, e, tokenNames);
>> }
>> 
>> @Override
>> public void emitErrorMessage(String message) {
>>  Command.getSession().out.println(message);
>> }
> 
> 
> 
> Arthur Goldberg wrote:
>> Hello All
>> 
>> I'm writing a parser for a fairly simple language (14 rules & 10 tokens) 
>> that reads a description of a graph -- like this OncoPrint 
>> <http://cbio.mskcc.org/cancergenomics-dataportal/index.do?case_set_id=gbm_3way_complete&tab_index=tab_visualize&action=Submit&genetic_profile_ids=gbm_mutations&genetic_profile_ids=gbm_cna_rae&genetic_profile_ids=gbm_mrna_zscores&case_ids=&Z_SCORE_THRESHOLD=1.0&cancer_type_id=gbm&gene_list=EGFR+ERBB2+PDGFRA+MET+KRAS+NRAS+HRAS+NF1+SPRY2+FOXO1+FOXO3+AKT1+AKT2+AKT3+PIK3R1+PIK3CA+PTEN&gene_set_choice=glioblastoma:_rtk/ras/pi3k/akt_signaling_%2817_genes%29&> 
>> -- of cancer data and produces a data structure that will be used to 
>> select, organize and filter the data to be shown in the graph. Users 
>> will enter the language on our web site.
>> 
>> I have a working one-pass grammar, but after building it found that it's 
>> very difficult to produce error messages in one pass. For example, one 
>> might think that a failed semantic predicate would be a good place to 
>> report an error, but that doesn't work because exceptions are not thrown 
>> when predicates are hoisted and predicates are called multiple times as 
>> the parser backtracks to find a parse. (See my previous message on use 
>> of semantic predicates and hoisting 
>> <http://www.antlr.org/pipermail/antlr-interest/2010-November/040091.html>.)
>> 
>> I simply want to say things like
>> "Syntax error at 'xyz' at char <c> on line <l>"   // when the input 
>> syntax is wrong (I can't say "line 1:0 no viable alternative at input 
>> 'xyz'"), and
>> "<input> is not a valid <type> at char <c> on line <l>"   // when the 
>> input semantics is wrong, for example when <input> should be a word that 
>> fits a pattern that describes a genetic data type
>> 
>> Therefore, I'm told that one should postpone error reporting until 
>> later, and that I need a two pass grammar -- 1) build AST, 2) walk the 
>> tree -- to easily and accurately report errors. I've started down that 
>> path, and have a few productions in each grammar and a driver program 
>> that connects them and handles bits of input.
>> 
>> I think that I can report the syntax errors by overriding
>>    public void displayRecognitionError(String[] tokenNames, 
>> RecognitionException e) and
>>    public String getErrorMessage(RecognitionException e, String[] 
>> tokenNames)
>> in Phase 1,
>> 
>> But it isn't clear how one accesses data in the AST with the tree 
>> grammar. That is, inside the tree grammar how do I get the data I need 
>> to produce the semantic error message above?
>> 
>> Is that documented? I don't see it in The Definitive ANTLR Ref, Chap. 8 
>> or 10.
>> 
>> Thanks & Thanksgiving
>> Arthur
>> 
> 
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
> 
> 
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address