[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX2: Exceptions
"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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|