Improved error reporting

["Howard M. Lewis Ship" <hl...@attbi.com>]

Recent criticism on the user list: exceptions report the object that failed
rather than the specification (or template) that failed.

Currently, syntax or simple consistency errors in specifications and
templates can tell you which file is wrong.  Errors in templates even
identify the line number.

Wouldn't it be neat if *all* errors identified the underlying file?

For example, I just had an error from an Image component that said:

"Parameter digit5 does not implement the IAsset interface."

That's because my OGNL expression was "digit" + digit    ... it should have
been getAsset("digit" + digit).

Now, the Image component could access the binding.  If the binding was
location tagged, then the exception could have reported the exactly file and
line that was in error.


Geoff ... you mentioned that you figured out how to "decorate" parsed DOM
tree with exact line numbers?

I think this would look something like:

public interface ILocationTagged
{
  public LocationTag getLocationTag();
}

LocationTag would simply be a holder of an IResourceLocation, line number
and column.

Lots of objects (especially bindings) would implement the interface.

Many exceptions would gain IResourceLocation, line number and column
properties ... extracting them from an appropriate argument.

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

Re: Improved error reporting

[Geoff Longman <gl...@intelligentworks.com>]

>
> Geoff ... you mentioned that you figured out how to "decorate" parsed DOM
> tree with exact line numbers?
>

Yup, but its quite ugly. I've customized the Xerces parser:

i.e. for tag
<some-tag attr="boo"/>

the parser records internally as Augmentations the following:

beginLineNumber + columnNumber and endLineNumber + columnNumber for the
start tag:

so 1,0 and 1,21 for <some-tag *********/>

and also the same for the attribute:

1,10 and 1,19 for  attr="boo"

what I don't have perfect yet is storing the same for close tags. Actually,
this past weekend I buggered the whole thing up a bit. need to fix it this
coming weekend.

However!There are some big downsides to this that would make it *really*
ugly to include in Tapestry

To record the info during the parse I had to change some classes in Xerces.
Plus I had to subclass the Xerces dom element and attribute classes to store
the Augmentation info where I can get at it in spindle.
DOM3 has get/setUserData() but Xerces as delivered supports only DOM2 and I
can't recompile the xerces plugin in Eclipse.

So the upside is that Spindle can access the location info. The downside is
that I'm tied to a customized version of Xerces.
Probably ok for Spindle but I doubt you'd be too keen on this for Tapestry!

Anybody out there know of a free (not GPL though) parser that'll do this out
of the box?


Geoff