#26 Clarify use of ErrorHandler

closed-rejected
nobody
None
5
2003-05-29
2002-12-10
Michael Kay
No

There appear to be differences between parsers as to
how they handle exceptions thrown by callback methods
in the ContentHandler (specifically, SAXException
exceptions). Some parsers notify these to the
registered ErrorHandler, others do not.

This makes it difficult for an application to ensure
that every error message is output exactly once.

(Specifically, Crimson does not notify such errors, and
I think most other parsers do).

It would be useful if the spec made it clear which is
the correct behavior. My own view is that it is better
if such errors are notified to the ErrorHandler.

Michael Kay

Discussion

  • David Brownell
    David Brownell
    2003-05-29

    • status: open --> closed-rejected
     
  • David Brownell
    David Brownell
    2003-05-29

    Logged In: YES
    user_id=44117

    The ErrorHandler spec says: "It is up to the application to
    decide whether to throw an exception for different kinds
    of errors and warnings".

    By explicitly throwing such an exception in a callback
    method, it has clearly decided already.

    AElfred has also always passed things through, and
    the SAX conformance tests referencing such logic
    (see the website, link to xmlconf.sf.net tests) have,
    as I seem to recall, reported it's mostly Xerces that
    has bugs preventing applications' handlers from
    throwing excpetions as designed.

     
  • Michael Kay
    Michael Kay
    2003-06-01

    Logged In: YES
    user_id=251681

    I don't think you've understood my comment.

    Suppose the SAX parser calls the user-written startElement
    method, and the startElement method throws an exception
    saying you can't have both a "debit" and a "credit"
    attribute. The question is, when control is returned to the
    parser with the exception return, should the parser call the
    user-defined ErrorHandler or not? Some parsers do, others
    don't, so you get different results running the same
    application with different parsers, and it's not clear from
    the spec which is correct.

    Specifically, if you try to do all your error reporting from
    the ErrorHandler, then with some parsers this will catch the
    application-detected errors, and with other parsers it
    won't. If you write the application on the assumption that
    the ErrorHandler is called in these circumstances, then the
    error will go unreported if the ErrorHandler isn't called;
    if you write the application on the assumption that the
    ErrorHandler isn't called, then the error will be reported
    twice in those cases where the ErrorHandler is called. I
    have found that the only way to get clean behavior with all
    parsers is to call the ErrorHandler from the application
    callback before throwing the exception, and then test within
    the ErrorHandler whether the error has already been reported.

    Michael Kay