Unit tests for JavaCC tokens and productions: InvocationTargetException ?
Cesare Zecca
http://groups.google.com/group/comp.compilers.tools.javacc/browse_thread/thread/e33401b7c7c81b66/553b77918b182618?lnk=gst&q=Unit+tests+for+JavaCC+tokens+and+productions#553b77918b182618
Date: Fri, 24 Aug 2007 07:44:08 -0400
AC wrote:
http://groups.google.com/group/comp.compilers.tools.javacc/msg/205986ef096b5fd3
> Here's a sample showing another approach to writing unit tests for
> JavaCC tokens and productions.
[...]
> Hope this helps!
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_thread/thread/dc7e343b5fbc099a/25eecf42abc74eef?lnk=gst&q=Context+dependent+enabled+identifiers+#25eecf42abc74eef)
[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?
AC
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.
Cesare Zecca
> java.lang.reflect.InvocationTargetException is a wrapper exception. [...]
Good suggestion, AC.
Thank you!