You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Howard M. Lewis Ship" <hl...@attbi.com> on 2003/03/15 22:51:07 UTC

You asked for it --- exception location information

A week or two ago a question popped up on the list: why can't Tapestry tell
me what line in my specification is broken?

Why not indeed?

I just spent a good chunk of time working on this, early results look great.
I've rewritten the Tapestry specification parser to use Jakarta Digester,
and added some hooks to track where in the document each element occurs.
This information is stored with the specification object and is accessible
at runtime.  When exceptions occur, the location is part of the exception.

The end result is exceptions related right to the offending file and line!

For example, I purposely mucked up a page specification:


org.apache.tapestry.BindingException 
Unable to resolve expression 'beans.required' for
examples.register.Register@172c47b[Register]. 
binding: ExpressionBinding[Register beans.required cachedValue=null] 
location: context:/WEB-INF/Register.page, line 32 
   
org.apache.tapestry.ApplicationRuntimeException 
Unable to instantiate bean 'required' (for component Register) as class
xxx.org.apache.tapestry.valid.StringValidator: Could not load class
xxx.org.apache.tapestry.valid.StringValidator from
org.mortbay.http.ContextLoader() / sun.misc.Launcher$AppClassLoader@12f6684:
xxx.org.apache.tapestry.valid.StringValidator 
location: context:/WEB-INF/Register.page, line 11 
   
org.apache.tapestry.ApplicationRuntimeException 
Could not load class xxx.org.apache.tapestry.valid.StringValidator from
org.mortbay.http.ContextLoader() / sun.misc.Launcher$AppClassLoader@12f6684:
xxx.org.apache.tapestry.valid.StringValidator 
   
java.lang.ClassNotFoundException 
xxx.org.apache.tapestry.valid.StringValidator 
Stack Trace: 
java.net.URLClassLoader$1.run(URLClassLoader.java:198) 
java.security.AccessController.doPrivileged(Native Method) 


Line 11 of the spec defines the "required" bean (it's the line where the
class name is wrong).
Line 32 of the spec is the binding that references the "required" bean.

If this involved implicit components in a template, the location would
reference the template.  I'm already finding this to be cool stuff.

I think it will take a while to tweak all this and get the ideal location
information into the exception report.


Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry