Property Node error clusters - to wire or not to wire?

[BobTheBeaver]

I was lately wiring error clusters all over my project and I'm wondering whether there are any benefits of wiring them to Property Nodes when I only wire constant references to VIs' inputs. Is there any reason to wire them anyway (assuming I use this certain VI only with constant references, which are known to be valid)?

[Bob_Schor]

Without having example code to clarify your question, it is difficult to make a response that "makes sense to me".  However, it is generally a Good Idea to include Error Lines going into and out of each of your subVIs, and (to the extent possible) ensure that (almost) all of your functions (including Property Nodes) that have Error In and Error Out are connected to the Error line.  This has several benefits:

• It provides a way to serialize LabVIEW functions in cases when normal Data Flow does not apply.
• If an Error occurs during the execution of a function, it can be recognized and handled by your code.
• The "cost" of including the Error Line is trivial (nano-seconds?), compared to the cost of poorly-characterized software.

Bob Schor

[BobTheBeaver]

Thank you for your response, I'll wire them then.

I was talking about situation like this:

https://snag.gy/jNpQsT.jpg

The only error with Property Node I've met so far was invalid reference. Here I'm using a constant reference, which disables a possibility of that error. Hence I was wondering if anything else can go bad, that could be possibly handled by error cluster.

P.S: You mentioned that ALMOST all of the function with error in/out should be connected. What are the exceptions?

[Kyle97330]

Even if the node in question doesn't generate an error, the general behavior for anything that has an INCOMING error is "do nothing, output all default values".  Wiring the error nodes of things you don't think could ever make an error has that same effect.  It may seem like what you're doing now is simple and not a big deal, but it's a good habit to get into.  In my experience, 99% of the time an error occurs you basically want to skip everything and get to the error handling code.  Mostly for time reasons (I don't want to sit around waiting for a lot of processing that will accomplish nothing because there was an error earlier that makes its results invalid) but it can also help with debugging if you can see the current status of all front panel objects at the time the error occurred.

It looks like you're making a SubVI there.  As a general rule, even if there are no calculations inside a SubVI, I always include error terminals.  It allows me to:

1) Control execution order via dataflow if important

2) Skip execution upon receiving an "error in"

3) If at a later date you add additional functionality to a SubVI that does have the possibility of an error, you don't have to rewire the error wires on every other VI you added it to in order to be sure you capture that error properly

There are a few functions you can skip wiring error in/out wires to.  One example is the "Format into string" node if you have a constant wired into the "Format string" input.  LabVIEW can "pre-check" a constant string to make sure it parses OK before you run a VI, but if you have a string that you assemble during execution it can't.  So if you have a constant wired in that lets you run, there's literally no way to get an error out of it.

[billko]

Since I usually have an "Error/No error" case structure to begin with, I usually don't wire the property node error clusters.  The exception is if I feel it is important to enforce data flow.  Besides, sometimes you WANT them to execute regardless of incoming error condition - many times the value of the property will depend on the error condition.