Hi Corey,
I think it's possible in the case of some exceptions to report something
through the ProblemListener interface. The difference would be that the
problem would be reported _after_ the exception is thrown and caught,
rather than before. Does that work for you, or do you depend on knowing
about the problem before the processor throws an exception and halts the
transformation? Also, some information may not be available in the call,
such as the source node and stylesheet node, although I might be able to
work things so that information can be reported. The line and column
number, and the URI of the problem would definitely be available.
What do you think?
Dave
Corey Tripp
<[EMAIL PROTECTED] To:
"'xalan-c-users@xml.apache.org'" <xalan-c-users@xml.apache.org>
search.com> cc: (bcc: David N
Bertoni/Cambridge/IBM)
Subject: RE: Problems with
ProblemListener
12/18/2002 11:03 AM
Hi Dave,
> Can you describe in more detail what you're doing, and
> what parts of the current mechanism work for you, and what could be
> improved (aside from obvious requirement of consistent behavior)?
Sure, in my application, which is multi-threaded, I have a framework for
reporting error/debug messages that occur. I want to be able trap all
error
messages from xalan and reroute them through my framework.
At first I was just using getLastError but this did not provide the details
(such as source file, line, and column) that I wanted. I have several xsl
files and without a source file name there is no easy way to locate the
problem file.
I came across the setProblemListener() in the XalanTransformer api and that
seemed like what I wanted (though I was confused for awhile with the
setWarningStream() method, what does it do anyway?).
I then realized that I should also have an ErrorHandler for parsing related
errors. I understand why this is because I also use xerces in another part
of my application and that's how they handle errors and such.
The parsing errors weren't going to the ProblemListener so I thought
everything was cool. I took out the calls to getLastError() because I had
thought that was covered and of course this was not the case.
So now I have all three and most of the time I get two error messages
reported, which is sort of anonying, but gets the job done.
I like the detail that is provided with the ProblemListener and being able
to redirect messages that xalan normal sends to cerr/cout.
Thanks,
-Corey