I'm looking into it as we speak, but as I do, would you mind running the test.cpp form my first post, to see which of the catch() sections triggers for you? I'm just really curious. Here's the source again for easy reference:
http://www.rutski89.com/static/xerces-test.cpp Thanks again for the help thus far, -Patrick On Tue, May 18, 2010 at 10:36 AM, Ben Griffin <[email protected]> wrote: > Well now, as I said, I'm not an expert on either xercesc or on exceptions but > what I see is > This is what is throwing the error to the handler. > -------------------------------------------------- > void XercesDOMParser::error( const unsigned int > , const XMLCh* const > , const XMLErrorReporter::ErrTypes errType > , const XMLCh* const errorText > , const XMLCh* const systemId > , const XMLCh* const publicId > , const XMLFileLoc lineNum > , const XMLFileLoc colNum) > { > SAXParseException toThrow = SAXParseException > ( > errorText > , publicId > , systemId > , lineNum > , colNum > , getMemoryManager() > ); > > // > // If there is an error handler registered, call it, otherwise ignore > // all but the fatal errors. > // > if (!fErrorHandler) > { > if (errType == XMLErrorReporter::ErrType_Fatal) > throw toThrow; > return; > } > > if (errType == XMLErrorReporter::ErrType_Warning) > fErrorHandler->warning(toThrow); > else if (errType >= XMLErrorReporter::ErrType_Fatal) > fErrorHandler->fatalError(toThrow); > else > fErrorHandler->error(toThrow); > } > -------------------------------------------------- > As I see it, the 'toThrow' exception is going to go out of scope as soon as > your error reporter returns - but then throwing instantiated exceptions this > way is one reason why i don't know or understand them - maybe it's fine. > > But my =guess= would be that you want to clone the exception - or treat it as > a temporary messenger object - which would indicate why your re-throw is > failing - as the memory is being recovered as the exception is passed out of > scope again. > > What do you think? > > > On 18 May 2010, at 15:22, Patrick M. Rutkowski wrote: > >> Oh! Oh! >> >> So it does throw to the catch(...), with the "unknown error"! >> >> That's exactly why it's broken! >> >> What's being thrown is a SAXParserException, which SHOULD be caught by >> the catch(SAXException& e)! not catch(...)! >> >> The weird thing is that when I run the test.cpp, which I originally >> posted, it does indeed get caught by the right hander, but then when I >> later run the same code in my actual project (which was the 2nd source >> listing in the original posted) it gets caught by a different handler! >> (the ... hander, which is wrong). >> >> I wonder if you'll see the point I'm trying to make there :-) >> -Patrick >> >> P.S. >> I haven't even read the rest of your message yet, I just really felt >> like responding to the first two line independently. >> I'll read the rest now though. >> >> On Tue, May 18, 2010 at 10:01 AM, Ben Griffin <[email protected]> wrote: >>> Yes it throws. >>> It is handled by your fatalError which then re-throws it to .. your >>> "unknown error" catch. >>> I don't know much about exception handling- in fact I avoid using them >>> when I can. >>> >>> Instead, I install a DOMErrorHandler and then gather messages until after >>> the parse. But that's me. >>> I use a single DOMLSParser which lasts for the duration of the process, and >>> then I let it manage the documents as it likes. >>> So my normal approach is to use my own 'loadDocument' method which deals >>> with the parsing and returns a DOMDocument, or a NULL >>> Here is a simple example, which actually comes from a bug report. >>> >>> #include <iostream> >>> #include <sstream> >>> #include <xercesc/dom/DOM.hpp> >>> >>> using namespace xercesc; >>> using namespace std; >>> >>> class myErrorHandler : public DOMErrorHandler { >>> ostringstream errors; >>> public: >>> bool handleError(const xercesc::DOMError& domError) { >>> char* msg = XMLString::transcode(domError.getMessage()); >>> errors << "[" << msg << "]"; >>> XMLString::release(&msg); >>> return true; >>> } >>> void errs(string& result) { >>> result = errors.str(); >>> errors.str(""); >>> } >>> myErrorHandler() : DOMErrorHandler() {} >>> }; >>> >>> int main(int argc, char *argv[]) { >>> const XMLCh ls_id [] = {chLatin_L, chLatin_S, chNull}; >>> XMLPlatformUtils::Initialize(); >>> myErrorHandler* errorHandler = new myErrorHandler(); >>> DOMImplementation* impl >>> (DOMImplementationRegistry::getDOMImplementation (ls_id)); >>> DOMLSParser* xmlParser = impl->createLSParser >>> (DOMImplementationLS::MODE_SYNCHRONOUS,NULL); >>> DOMConfiguration* conf (xmlParser->getDomConfig ()); >>> conf->setParameter(XMLUni::fgDOMErrorHandler,errorHandler); >>> conf->setParameter(XMLUni::fgXercesCacheGrammarFromParse,true); >>> conf->setParameter(XMLUni::fgXercesUseCachedGrammarInParse,true); >>> conf->setParameter(XMLUni::fgXercesSchema,true); >>> conf->setParameter(XMLUni::fgXercesIgnoreCachedDTD,false); >>> conf->setParameter(XMLUni::fgDOMValidate,true); >>> DOMDocument *foo = NULL; >>> xmlParser->loadGrammar("foo.xsd",Grammar::SchemaGrammarType,true); >>> foo = xmlParser->parseURI("foo.xml"); >>> string err; >>> errorHandler->errs(err); >>> cout << "Errors for foo.xml:" << err << endl; >>> XMLPlatformUtils::Terminate(); >>> return 0; >>> } >>> >>> Adding memory inputsource is a bit more tricky - but I do it something like >>> this: >>> >>> const XMLCh *mem = {chLatin_M, chLatin_E, chLatin_M, chNull}; >>> std::string xmlfile = "<? xml version="1.0" ?><bla bla bla />" ; >>> DOMDocument *foo = NULL; >>> DOMLSInput *input = ((DOMImplementationLS*)impl)->createLSInput(); >>> XMLByte *xmlraw = (XMLByte*)(xmlfile.c_str()); >>> MemBufInputSource *mbis = new MemBufInputSource(xmlraw,xmlfile.size(),mem); >>> mbis->setCopyBufToStream(false); >>> input->setByteStream(mbis); >>> input->setEncoding(XMLUni::fgUTF8EncodingString); >>> try { >>> foo = parser->parse(input); >>> } catch (...); //deal with parser throws here! >>> input->release(); >>> >>> I cannot say that eny of this is the right way to do things, but maybe it's >>> of some use to you? >>> Lots of people use SAX instead of DOM, which depends upon your purpose of >>> course. >>> >>> Not really sure that any of this helps. >>> I am really STILL LEARNING xercesc after five years. Just ask Alberto how >>> annoying I can be at times :D >>> >>>> Well, yeah, I am just learning the basics :-) >>>> >>>> But I figured that deleting the XercesDOMParser and returning the >>>> DOMDocument would be wrong, because the XercesDOMParser owns the >>>> DOMDocument, no? >>>> >>>> -Patrick >>>> >>>> P.S. >>>> Did running my "broken" code on your machine trigger the catch(...) or the >>>> catch(const SAXException& e)? >>>> >>>> On May 18, 2010, at 7:08 AM, Ben Griffin wrote: >>>> >>>>> I had a look at your 'broken' source. >>>>> There was no main function, so I added one in as follows: >>>>> >>>>> int main() { >>>>> XMLPlatformUtils::Initialize(); >>>>> XercesDOMParser* parser = ParseXML("input"); >>>>> return 0; >>>>> } >>>>> >>>>> I commented out the QK:: push stuff, because it's not part of the library >>>>> (that I know of). >>>>> >>>>> I added >>>>> #include <xercesc/parsers/XercesDOMParser.hpp> >>>>> >>>>> I don't have / don't use util.hpp so I added >>>>> namespace { >>>>> typedef std::basic_string<XMLCh> XercesString; >>>>> } >>>>> >>>>> Regardless, I have sent you the source code directly. >>>>> It compiles and runs. >>>>> >>>>> I don't really know why you would want to return the parser having parsed >>>>> a file. Normally one wants the document from the parse. >>>>> Maybe you are just getting the basics up first...! >>>>> >>>>> >>>>> On 18 May 2010, at 12:01, Patrick Rutkowski wrote: >>>>> >>>>>> If any of you Xerces-C devs are up for it, I would be willing to go as >>>>>> far as doing a screen-sharing session to debug this, since it seems to >>>>>> be impossible to reproduce. I have my version of xerces already built >>>>>> with -g -O0 even. >>>>>> >>>>>> Of course, that might amount to you helping me find a silly big in my >>>>>> code somewhere, free of charge, which might seem unfair. Then again, >>>>>> maybe it really is an obscure bug in Xerces, which would make it worth >>>>>> it. >>>>>> >>>>>> I dunno, I just don't know what to do anymore :-/ >>>>>> >>>>>> -Patrick >>>>>> >>>>>> On May 18, 2010, at 2:47 AM, Vitaly Prapirny wrote: >>>>>> >>>>>>> Patrick Rutkowski wrote: >>>>>>>> I have verified with test prints and gdb that fatalError() >>>>>>>> in ThrowErrorHandler is indeed triggered like it's supposed >>>>>>>> to be, so we're good so far. >>>>>>> >>>>>>> So the parser->setErrorHandler() is not broken actually, your subject >>>>>>> line misleads. I could assume your toolchain or project is >>>>>>> somewhat broken. If you could prepare a minimal self-contained test case >>>>>>> it would be very helpfull to someone who wished to look at it. >>>>>>> >>>>>>> Good luck! >>>>>>> Vitaly >>>>>> >>>>> >>>> >>> >>> > >
