OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: SAX2: Exceptions

[ Lists Home | Date Index | Thread Index ]
  • From: "Mark D. Anderson" <mda@discerning.com>
  • To: David Brownell <david-b@pacbell.net>
  • Date: Tue, 21 Dec 1999 14:55:09 -0800

> If you catch an exception, you get to decide how to continue
> processing starting at the point you caught it, including the
> optional rethrow of that exception after local cleanup.  Same
> in Java and C++ -- once you throw, the stack unwinds till some
> handler says to stop unwinding, continue from there.  Right?
> (My C++ has gotten rusty.)

sure. that doesn't mean your parser wants you to go calling
random functions while you are in your exception handler.
this is mostly a documentation issue, about the underlying state
machine in the principal objects of the api.

>> personally i prefer that -- i don't like using exceptions as a
>> message sending mechanism. but then there does need to be a way
>> to signal warnings that don't mean that parsing can't be continued,
>> if you follow my double-negative drift.
> 
> Like the ErrorHandler does, right?  Am I missing something, this
> seems like an obvious answer, no reason for Java or C++ to differ.

yes, that is fine.

> Re pointer-v-ref, I'm used to throwing refs -- fewer opportunities
> to leak exception objects, no heap interactions.

Yes well, this gets into religious issues that are about as strong
as how to represent strings. As long as the API makes clear what its
intended usage model is i'm happy, since any can be made safe with
sufficient work.

> I'll confess I didn't quite notice any MT issues in that post, but as you
> stated it was really a "what Parser/InputSource is in use" issue that
> isn't MT-specific at all.
> 
> I can't see a way confusion could arise there unless one parser callback
> needs to invoke some other parser, and is sloppy about letting exceptions
> from that invocation appear as if they were exceptions from the current
> invocation.  There are always ways to create bugs if code isn't careful.

if i have a single catch which is "above" multiple simultaneous parsing
activities, then how can i determine from the exception object alone
which parser is involved? or is the answer to not do that?

-mda


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS