You are viewing a plain text version of this content. The canonical link for it is here.

Posted to c-users@xalan.apache.org by Corey Tripp <Co...@InformativeResearch.com> on 2002/12/18 18:02:55 UTC

Problems with ProblemListener

Hi,

  I have a created a custom ProblemListener and ErrorHandler that I give
xalan to so that I can capture problems and error and report then through my
application's error handling mechanisms.  However I've noticed that some
problems do not always make it to the ProblemListener or ErrorHandler and
can only be reported by calling getLastError() on the transformer object
after an error has been detected.

  The result of this is that for most errors I have to messages one from
ProblemListener or ErrorHandler and then from getLastError().  There is no
harm in reporting the same error twice, but it would be nice to avoid it if
I can.

  Is there any way to tell by the return code of the transformer that the
error encountered was reported through the ProblemListener and thus no need
to call getLastError?

  If I remember right the error that was not reported happened in the actual
processing not in the parsing, compiling of the stylesheet or the parsing of
the input source.  Sorry I do not remember the exact nature of the error it
happened some weeks ago.

Thanks,

-Corey

Re: Problems with ProblemListener

Posted by David N Bertoni/Cambridge/IBM <da...@us.ibm.com>.

Hi Corey,

This doesn't surpise me. Error handling is one of the most inconsistent
things in the code, and I've been trying to figure out the best way to
straighten it out. On one hand, the ProblemListener mechanism is nice
because it allows users to plug in special handling. Unfortunately, it's
also intrusive, and requires the propagation of an object throughout the
runtime.

What you're likely seeing is that some errors are handled by throwing
exception in the code, while others are handled by the error listener,
which then throws an exception. One option is to change the
ProblemListener interface so it doesn't have to throw the exception. That
would mean we could throw more problem-specific exceptions, rather than a
generic one with an error message. Of course, the ProblemListener would be
free to throw an exception, if that's the right thing to do.

ErrorHandler is a different beast altogther, as it's supplied by Xerces.
Integrating that with the ProblemListener interface could be difficult.

One of the first things to do with a redesign is to discover what the
requirements are. 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)?

Dave

Corey Tripp
<CoreyT@InformativeRe To: "'xalan-c-users@xml.apache.org'" <xa...@xml.apache.org>
search.com> cc: (bcc: David N Bertoni/Cambridge/IBM)
Subject: Problems with ProblemListener
12/18/2002 09:02 AM

Hi,

I have a created a custom ProblemListener and ErrorHandler that I give
xalan to so that I can capture problems and error and report then through
my
application's error handling mechanisms. However I've noticed that some
problems do not always make it to the ProblemListener or ErrorHandler and
can only be reported by calling getLastError() on the transformer object
after an error has been detected.

The result of this is that for most errors I have to messages one from
ProblemListener or ErrorHandler and then from getLastError(). There is no
harm in reporting the same error twice, but it would be nice to avoid it if
I can.

Is there any way to tell by the return code of the transformer that the
error encountered was reported through the ProblemListener and thus no need
to call getLastError?

If I remember right the error that was not reported happened in the
actual
processing not in the parsing, compiling of the stylesheet or the parsing
of
the input source. Sorry I do not remember the exact nature of the error it
happened some weeks ago.

Thanks,

-Corey