[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
To: "Karl Waclawek" <karl@waclawek.net>
Cc: "David Megginson" <dmeggin@attglobal.net>; "XML Developers List" <xml-dev@lists.xml.org>; "SAX
Developers' List" <sax-devel@lists.sourceforge.net>
Sent: Friday, March 05, 2004 12:22 PM
OK, I am replying only to the lists now.
This "Reply All" has escalated to the point where I get 5 identical
replies to my reply.
> My gut is that when the handler throws an exception it is not
> reported to fatalError. According to the ErrorHandler documentation,
> "The parser will then report all errors and warnings through this
> interface." The documentation of the three methods indicates this as
> well. For instance, fatalError "corresponds to the definition of
> "fatal error" in section 1.2 of the W3C XML 1.0 Recommendation. For
> example, a parser would use this callback to report the violation of
> a well-formedness constraint."
The question is: why can the exception argument passed to fataError()
wrap another exeption then?
> I see no text that indicates a user thrown exception should ever be
> passed to the ErrorHandler. Should endDocument be called even in the
> event of a user-thrown exception? I suspect not. The user threw it.
> Let them clean up after it.
That would negate the "cleanup" potential of endDocument.
I am not against this, as it is the normally expected behaviour
when an exception is thrown, but I would consider parser exceptions
no different from user exceptions.
So, what you are saying is:
- if fatal error, call endDocument
- if exception, do the normal thing (i.e. don't call endDocument)
I can live with that.
Karl
|
