Bug in NI_XML.lvlib:Get First Non-Text Child.vi

[David_Staab]

This VI fails to handle the output of the first Property Node on its block diagram. Here's a screenshot of the BD in LV 2013 SP1:

Here's a fixed version:

[AirFrantz]

David,

I'm not sure that this is actually unexpected behavior.  When you try to run this subvi without any child classes, does the subvi return an error?  There is a boolean output also that should be either true or false based on the existence of a child or not.  In order to file a bug report, I will have to be able to reproduce this issue myself.  What are you using this subvi for and where are your problems arrising from?

[David_Staab]

Jon -

I was using the VI for its stated function: To get the first non-text child in an XML tree. My problems arise from an error that is thrown by the Property Node when a leaf node is accessed by this VI.

The VI has a Boolean output to indicate whether a child node exists. That information -- whether a child exists -- should be funneled through this output, and internal errors related to the information should be handled gracefully. That's just good encapsulation. Bubbling internal errors up to the caller in addition to reporting the condition on the interface is a leak in the encapsulation.

It's evident that the intent of the VI's interface is to encapsulate the logic required to find a non-text child node and get a reference to it. That logic isn't being encapsulated, so I call it a bug.

[RavensFan]

I disagree this is a bug.  I really don't see how your code in the end behaves all that differently than the original code.

Both will produce an error if there is no child node.  The original will try to execute some nodes downstream, but because of the incoming error, and that they would use normal LabVIEW error handling where nodes don't execute on an incoming error, those nodes won't execute.

[David_Staab]

RavensFan, I did run both versions before posting this. The second diagram doesn't throw an error because the second property node ("type") is the one that normally would upon receiving a null refnum. The first property node returns null without throwing an error (as is described in the "firstchild" property's help doc).

[Darin.K]

I agree with David, but I hesitate to call it a bug.  Spewing meaningless errors into unrelated parts of your code is on the NI-sanctioned Error-handling Greatest Hits album so it is probably intentional.

There are 4 scenarios here to consider:

1) Bad reference passed in

2) Good reference, no child nodes

3) Good reference, no non-text child nodes

4) Good reference, 1 or more non-text child nodes.

What are the outputs:

1) Error message from first PN, boolean false, NotARefnum

2) Error message from second PN, boolean false, NotARefnum

3) No Error, boolean false, NotARefnum

4) No Error, boolean true, valid Refnum

How is an outsider suppposed to know from the error messages which of 1 & 2 happened?  You have to know what goes on inside and see which node threw the error.  Having to know the insides of a VI to decipher an error message is not good API design IMO.

What should happen in my opinion is the following:

Input check, invalid refnum throws an error clearly indicating "Bad refnum input"

The output refence would only be valid in case 4, so the boolean is redundant, but I would include it as a usability measure.  No errors should be thrown in cases 2-4, no text nodes versus no nodes at all is almost certainly a distinction without a difference in this case.

David's fix cleans up the unhelpful error message being thrown during an unsuccessful search of a valid refnum.  I would add an input validation check in the interest of providing a useful error message and not the "random property called with bad reference" error.

[Daniele88]

Case 2 and 3 should evidently provide the same output. When I call this VI I am asking the system whether a non-text child does exist or not: the answer should be either a yes, if the node exist, or a no, if the node does not exist. Why should I get an error if there are no text child in my node? I am asking about non-text node