SAX2: Exceptions

Mark D. Anderson mda at
Tue Dec 21 23:00:13 GMT 1999

> 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?


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

More information about the Xml-dev mailing list