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
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
"il-antlr-interest" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
