SAX2: Exceptions

[David Brownell]

"Mark D. Anderson" wrote:
> 
> > > which ones are continuable?
> >
> > Neither Java nor C++ has "continuable" exceptions; what are you
> > talking about?
> 
> sorry, i didn't mean it in the technical sense.
> but instead asking whether all exceptions are going to be "fatal".

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.)


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


> > > there are also potential MT issues which i mentioned on a SAX2 thread
> > > a few weeks ago.
> >
> > Perhaps you could give a pointer to the archive entry.
> 
> this was intermixed in the "SAX/C++: C++-specific design principles" thread
> at http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Dec-1999/0368.html

Re pointer-v-ref, I'm used to throwing refs -- fewer opportunities
to leak exception objects, no heap interactions.  That'd imply (only
for C++) that ErrorHandler also gets a ref, and if it chose to report
an exception it'd be throwing that ref.  Assuming (for sake of example)
that the error handler's a non-null object pointer:

	errorHandler->error (SAXParseException (... constructor args...));

and (if memory serves)

	error (SAXParseException &exception)
	raises SAXException
	{
		if ( ... it's evil enough ... ) {
			throw exception;
		}
		...
	}

[ The discussions on the C++ binding have been largely ignored by yours
truly, particularly the suggestions to ignore/reinvent standard APIs, or
otherwise to encourage use of retro nonconformant C++ implementations now
that the C++ spec has finally been "blessed".  Most of the relevant features
have been stable for a very long time, as I understand things. ]


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.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)