[Mono-list] XSLT debugging ...

Michael Meeks michael.meeks at novell.com
Fri Nov 24 06:27:23 EST 2006

Hi Atsushi,

On Fri, 2006-11-24 at 13:36 +0900, Atsushi Eno wrote:
> > 	So - my question is - how do people debug 55k lines of XSLT ? :-)
>> and - more to the point, when something fails how do we get a decent
>> 'stack trace' from the XSLT code ? [ I tried adding some 'Call
>> Template' tracing debug - as you see, but quickly get swamped ].
> People doesn't debug XSLT in such way. People just reduce extra
> transformation parts, reduce imputs and trim down to doubtful blocks.

	This is a method I call "binary chop" - it works well when you're
writing new code, and introduce a small number (preferably 1) of
bugs :-), and when the code is easy to understand & partition, but when
there are a potentially arbitrary number of vicious problems and
interactions, and the code is not easy to reduce reliably, it's not such
a powerful tool.

	Is this how you fix all your problems ? there is no verbose debug
output you use or better tracing logic ?

> > 	What I would -love- would be a simple piece of code that just dumped
> > the file/line information to the console (or Debug. or whatever) and
> > re-threw the exception, perhaps in 'XslTemplate.Evaluate' or something
> > (?) [ we get a good number of frames of that ].
> In such case you could just use mono-xmltool to debug your XSLT.

	Well - unfortunately, that's not really feasible - the XML that the
XSLT produces is concealed away and produced by pre-processing a ton of
random other files into each other (AFAICS on demand by the XSLT) ;-) so
it is rather hard just to pull out the XML [ though of course this is a
good suggestion ].

> Or just wrap around the entire transformation with "try" and "catch
> XsltException", and get LineNumber and LinePosition from there.
> Actually its Message property indicates them, so you don't have to
> retrieve those numbers.

	Well - the problem here is that the exception / evilness is thrown by
code run -from- the XSLT code, not the code itself - so the real
exception is some random "Stack Empty during .pop()" type thing. Of
course the -real- problem is that the XSLT script has (somehow) managed
to produce more element closes than opens :-) getting a trace of where
we were in those 55k lines when that happened -might- help find where we
go wrong.

> Any omitted information wouldn't result in better debugging. That is not
> what we call "good diagnostics".

	I find that hard to parse. However, since you appear reluctant to help,
I will try and dive in and implement something to emit more of the
omitted information :-) perhaps that will help me find the root problems
more quickly.



 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot

More information about the Mono-list mailing list