[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX/Java Proposed Changes

• To: <xml-dev@l...>, <sax-devel@l...>
• Subject: Re: SAX/Java Proposed Changes
• From: "Karl Waclawek" <karl@w...>
• Date: Mon, 8 Mar 2004 20:01:48 -0500
• References: <1078627030.23151.ezmlm@l...> <404B5CA1.7070000@i...> <p06010203bc71316af8e7@[192.168.254.4]> <404CD7D4.90106@i...> <p06010215bc72919abd26@[192.168.254.4]>

----- Original Message ----- 
From: "Elliotte Rusty Harold" <elharo@m...>
To: "Jochen Wiedmann" <joe@i...>
Cc: <xml-dev@l...>; <sax-devel@l...>
Sent: Monday, March 08, 2004 4:12 PM


> At 9:30 PM +0100 3/8/04, Jochen Wiedmann wrote:
> >Elliotte Rusty Harold wrote:
> >
> >>  Then your code will break when used with some of today's parsers 
> >>which do call endDocument() after a fatal error.. :-(
> >
> 
> I'm not sure what this program is supposed to demonstrate. One of the 
> conclusions I think we're reaching is that if a client supplied 
> method such as startDocument() throws an exception, then endDocument 
> (and fatalError()) are not called. 

In that case, endDocument() should also not be called in the
case of a parser generated exception. I don't see why one should
treat a client generated exception differently, it would just
make client code more complicated.

> endDocument() and fatalError() 
> are for the use of the parser only. If the client chooses to 
> prematurely abort processing by tossing an exception, then the client 
> has the responsibility to clean up before doing so. 

I think cleanup responsibility is determined by what you
"own", not by where the exception originates.

Karl

• References:
  • Re: SAX/Java Proposed Changes
    • From: Jochen Wiedmann <joe@i...>
  • Re: SAX/Java Proposed Changes
    • From: Elliotte Rusty Harold <elharo@m...>
  • Re: SAX/Java Proposed Changes
    • From: Jochen Wiedmann <joe@i...>
  • Re: SAX/Java Proposed Changes
    • From: Elliotte Rusty Harold <elharo@m...>

• Prev by Date: Re: SAX/Java Proposed Changes
• Next by Date: cannot resolve symbo: class DOMParser with DOM and xerces-2_2_1
• Previous by thread: Re: SAX/Java Proposed Changes
• Next by thread: Re: [Sax-devel] Re: SAX/Java Proposed Changes
• Index(es):
  • Date
  • Thread