Exception support

[GoogleCodeExporter]

It would be useful for some methods of xml_node or xml_attribute to throw an 
exception if it fails, especially when chaining.

For example:
pugi::xml_node = root.child("foo").child("bar"). ...
If <foo> does not have a child named <bar> -> throw an exception.

I know the xpath implementation supports exceptions, but xpath is not always 
the ideal solution to the problem.

Perhaps with conditional compilation, both approaches (with or without 
exceptions) can be supported.
Alternatively, some methods could be overloaded or get an extra bool 
throw_if_failure = false parameter?

This is currently the only feature I'm missing in an otherwise great library.

Original issue reported on code.google.com by patrick....@gmail.com on 13 May 2012 at 2:27

[GoogleCodeExporter]

Note that XPath generally does not throw exceptions during evaluation (except 
if it runs out of memory or if select/select_single_node is used with a query 
that does not return node sets), so select_single_node("foo/bar") will return 
an empty node.

Generally it's preferable to chain multiple expressions and just check the 
result - i.e. pugi::xml_node node = root.child("foo").child("bar"); if (!node) 
...
I guess there are some cases where it's useful to check intermediate nodes 
(better error reporting?). I'll think about what makes sense here...

Original comment by arseny.k...@gmail.com on 13 May 2012 at 4:11

[GoogleCodeExporter]

but that would mean a change in functionality. I depend on the fact that 
root.child("foo") gives you an empty child, if foo doesn't exist. and that 
root.child("foo").child("bar") still gives you an empty child. 

in the end, all I want is the item foo:bar:rab, if it exists and i don't want 
to do if (!root.child("bar").empty() && !root.child("bar").child("foo").empty() 
&& !root.child("bar").child("foo").child("rab").empty() ) { do somethign }. the 
present state is just better.

throwing an exception in this case is just a mess. if it's not there, it's just 
not there.

Original comment by piz...@gmail.com on 13 Oct 2012 at 9:42

[GoogleCodeExporter]

I thought about this a bit and it seems that this request just contradicts the 
way pugixml does things.
Adding an additional error handling mechanism makes the interface more 
fragmented and complicated.
Obviously changing the existing approach to use exceptions is a no-go since it 
breaks existing code.
Additionally not all platforms have exception support; adding a completely 
different error handling mechanism to pugixml while having it disabled for 
certain build configurations seems backwards.

(note that XPath implementation throws an exception if the query is invalid, 
but does not if exceptions are not supported/enabled; I think I would have 
preferred it to never throw, but there were valid reasons behind the design, 
and the decision can't be changed at this point anyway)

Original comment by arseny.k...@gmail.com on 20 Dec 2013 at 5:45

• Changed state: WontFix