Hi Don,
> >You can set the ProblemListener for the XalanTransformer instance, and
most
> >errors (but not all, unfortunately) will come through the call. See the
> >classes ProblemListenerDefault and XalanTransformerProblemListener for
more
> >information. The purpose of the latter is to allow re-direction of
> >warnings to a stream specified by the user.
> I've looked at these classes, but how do I use them? Can I use these
classes
> as is, or do I need to derive my own class from ProblemListener to cache
the
> line and column number information?
You would probably want to derive your own. ProblemListenerDefault writes
characters to a supplied stream. The default operation in XalanTransformer
is to give DefaultProblemListener a stream that appends character to a
XalanDOMString. This string is what's returned from getLastError(), if any
data was written to it. If not, XalanTransformer asks the exception for
the character string it contains. You probably want to doing something
different, so you can just derive from ProblemListener and do what you want
with the data it gets.
> From the behavior of XalanTransformer::transform(), which is to write the
> error message to cerr (I think), I assumed that a DefaultProblemListener
> exists and is part of my XalanTransformer object. But if that is so, why
> do I get a null return from getProblemListener?
It's a transient stack-based object, so it's not a member of the class.
XalanTransformer::getProblemListener() only returns a pointer to the
ProblemListener instance installed by the user.
> Hmm, I don't think I ever see line number information from getLastError,
for
> any error. At any rate, it's easy to create the problem. Here's a simple
> stylesheet:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
> version="1.0">
> <xsl:template match="@*|node()">
> <xsl:apply-templates select="@*|node()">
> </xsl:template>
> </xsl:stylesheet>
Ahh yes, a SAX parsing error. This is a bug, but there's no real
workaround for it -- it's just part of the whole problem we have dealing
with multiple exception hierarchies and multiple error handling mechanisms.
However, the line number information will come through in the
ProblemListener call, and also will come through in the warning that's
written to the stream. Yes, this comes through as a warning in the
ProblemListener, because if it were to come through as an error, the
ExecutionContext instance would be obliged to throw its own exception,
rather then let the parsing code throw the appropriate SAX exception.
Needless to say, I really want to clean up the ProblemListener/error
reporting stuff so exceptions are thrown at the point where the error
occurred, and not the ExecutionContext. The code is quite schizophrenic
right now, because some exceptions are thrown from the code where the error
occurred, while others are thrown from the ExecutionContext. This is an
ongoing problem. Sigh...
I also see that we're not passing the line number information on to the
SAXParseException, so if I fix that problem, at least the error message
could contain the line information.
Hope that helps...
Dave
