Hi Dave,
That sounds good. I'm not really concerned with the timing, whether the problem is reported before or after an exception is thrown and caught. Same with the source node and stylesheet node, they are nice but not completely necessary, as long as the URI, line, and column are there. Heck, I can live without the line and column if I have URI :) at least that provides a starting point of where to look. Thanks, -Corey > -----Original Message----- > From: David N Bertoni/Cambridge/IBM > [mailto:[EMAIL PROTECTED] > Sent: Friday, December 20, 2002 1:27 PM > To: [email protected] > Subject: RE: Problems with ProblemListener > > > > > > > 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: > "'[email protected]'" > <[email protected]> > 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 > >
