In
http://groups.google.com/group/comp.compilers.tools.javacc/browse_thr...
Date: Fri, 24 Aug 2007 07:44:08 -0400
http://groups.google.com/group/comp.compilers.tools.javacc/msg/205986...

[...]

All that worked excellently. I was able to test a given specific
production by mean of the

        public
        GplProductionException
        runProductionRule
        ( String pMethodName
        , String pInput
        , List<String> pExpectedTokenImages
        );

        public
        Throwable
        runProductionRule
        ( String pMethodName
        , String pInput
        );

A few days ago I integrated JTB, cleaned up the grammar by the Java
code and moved some context sensitive controls to the AST visitor
class. After integration of JTB most of the utests continue to run
successfully but a couple of ones raise some exceptions. For instance

        void
        IdRef() :
        {}
        {
                <ID> ( <FIELD_ACCESSOR>  <IDENTIFIER> )*
        }

o -  <FIELD_ACCESSOR>  is the usual "." operator.
o -  <ID> is a reserved token (currently the "id" keyword)

I slightly updated the utest to allign the suite to the improved
parsing checks, with changes concerning some case studies being
tested.

        public void testIdRef()
        {
                String lMethodName = "IdRef";
                GplProxy lGplProxy = GplProxyImpl.istance();

        [1]     assertNotNull( lGplProxy.runProductionRule( lMethodName,
"id" ) );
        [2]     assertNull( lGplProxy.runProductionRule( lMethodName, "somma( id;
myGroup )" ) );
                ...
        }

[1]: id would be syntactically correct except for the context (see
also
http://groups.google.com/group/comp.compilers.tools.javacc/browse_thr...)
[2]: here somma() is a group function used to create the right context
but that input does not conform to IdRef()

At the test case [2] I noted that I get an InvocationTargetException
at the statement marked [3]

          static final public IdRef IdRef() throws ParseException {
           NodeToken n0;
           Token n1;
           NodeListOptional n2 = new NodeListOptional();
           NodeSequence n3;
           NodeToken n4;
           Token n5;
           NodeToken n6;
           Token n7;
        [3]  n1 = jj_consume_token(ID);
                     n0 = JTBToolkit.makeNodeToken(n1);
            label_5:
            ....

I regressed everything to the pre JTB integration version, as well,
being able to reproduce the same behaviour (same exception raised at
[3'])

          static final public void IdRef() throws ParseException {
        [3'] jj_consume_token(ID);
             label_5:
             ...

So, my deduction is
o -  it is NOT a problem due to the integration with JTB
o -  jj_consume_token(ID) expects exactly an <ID>. It likely works as
designed. It gets the "somma" troken (an <IDENTIFIER>) and crashes.
Well, it seems a quite awkward behaviour to raise an
InvocationTargetException, instead of a specific lexer error exception
(ParseException or TokenMgrError), but I do not know the details  of
the JavaCC machinery.
I tried to reproduce the situation using another productions that
expects a specific token category (an <IDENTIFIER>) as first part of
the input

        void
        TableElement() :
        {}
        {
                <IDENTIFIER>  <SQUARE_OPEN>  DisjunctiveExpression()
<SQUARE_CLOSED>
                ...
        }

and I get, at [4]

        public void testTableElement()
        {
                String lMethodName = "TableElement";
                GplProxy lGplProxy = GplProxyImpl.instance();

        [4]     assertNotNull( lGplProxy.applicaProduzione( lMethodName ,
"1234" ) );
                assertNull( lGplProxy.applicaProduzione( lMethodName ,
"table[3]" ) );
                ...

again an InvocationTargetException, specifically at [4']

          static final public void TableElement() throws ParseException {
         [4'] jj_consume_token(IDENTIFIER);
              jj_consume_token(SQUARE_OPEN);
              ...

I think that a "regular" behaviour should raise either a
ParseException or a TokenMgrError, not an...

"InvocationTargetException is a checked exception that wraps an
exception thrown by an invoked method or constructor."

That sound as a signal of danger: if so, I think that there is
something wrong. What?

java.lang.reflect.InvocationTargetException is a wrapper exception.  I
suspect you may be seeing this because test runners like JUnit use
reflection to inspect a test class and find its test methods, and then
invoke each test method.  When a test method invoked via reflection
throws an exception, reflection wraps the exception in an
InvocationTargetException.   So look inside the wrapper, and find the
exception that caused it.

On May 11, 8:13 pm, AC <u...@domain.invalid> wrote:

Good suggestion, AC.
Thank you!