> > From: andy glew amd com [mailto:andy glew amd com] > > Q: what should Node::find( nonexistent_xpath ) > > return if it is called with an xpath that does not exist? > > > > libxml2 returns 0 xmlXPathEval ... > > which is the "inside" of Node::find(), > > but Node::find() core dumps. > > That's not good. > > > I.e. libxml2 is better behaved that libxmlpp::find() > > in this regard. > > > > I strongly suspect that libxmlpp should return an empty set. > > I guess it should throw an expection. A patch would be very welcome. Patch attached. Unidiff -u 20, prepared from cvs diff in my local repository. My version of patch doesn't seem to be able to figure out file to patch automatically, but there's only one... libxml++/nodes/nodes.c I chose the fix that most quickly solved my problem: having libxml++ return an empty NodeSet when libxml2 does. I did NOT choose to throw an exception as Murray suggested, since (1) that would make my code using it more complex, and (2) it is onconsistent with libxml2. Long term the right way is to do what Stefan Seefeld suggested, returning an XPathResult that unifies NodeSets and other xpath return types. I'm not bothering to do that yet, since I have not decided whether to use libxml++ or Xerces or xml4c, the IBM C++ binding. I owe a few more patches, but am reluctant to do so until there is a testing framework for libxml++. Does one of the developers (Murray?) have a preference for a testing framework?
Attachment:
nonexistent-xpath-empty-nodeset-bugfix--2003-05-06.patch
Description: Binary data