Re: [xml-dev] Re: [Sax-devel] Re: [xml-dev] SAX/Java Proposed Changes
Brought to you by:
dmegginson
From: Karl W. <ka...@wa...> - 2004-03-05 18:02:16
|
----- Original Message ----- From: "Elliotte Rusty Harold" <el...@me...> To: "Karl Waclawek" <ka...@wa...> Cc: "David Megginson" <dm...@at...>; "XML Developers List" <xm...@li...>; "SAX Developers' List" <sax...@li...> 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 |