Quick question for the LabVIEW experts - I try to include Error In and Error Out clusters ICON terminals in all of my VIs. My question is however, if I have a VI with code that does not use any error terminals do I need to include Error In and Error Out clusters in that VI? If my code does not use those terminals I would think that I'd just be passing errors right through this VI and I don't see a purpose of including them.
I can think of two reasons you still may want to carry the error though.
Data Flow, this helps keep things in order by passing the error around forcing VIs to be called after other VIs. If you really want them to run in parallel then don't wire in the error.
Skip if error, pass in the Error In, then wire it to a case structure, and put all your code in the No Error case. This will at least keep your code from running if there is an error. Just like DAQmx, no need to perform the Read VI if the Init returned an error. Also it helps speed up a shutdown in case of an error because once the error happens all your code essentially skips doing the stuff it wants. Just make sure things like Cleanup still run if there is an error.
I fully agree with Hooovahh. But I do find myself putting less and less error clusters in my VIs simply because I don't need to handle errors in those VIs and/or nothing in my VI with throw any errors.
But I do find myself putting less and less error clusters in my VIs simply because I don't need to handle errors in those VIs and/or nothing in my VI with throw any errors.
Not all VIs need Error In and Error Out that's cool. But If you really don't need Error In or out, you are saying, the flow control through other means is sufficient, no errors the VI can generate are ever useful, and if an error occurs there is no need to skip the VI.
For me very seldom does real code not need the things I mentioned, so I'd say in a medium to large sized project I may have written 0-5 VIs that don't have error in or out.
Having said that I was hoping that NI was going to follow through with their stated intention to put error IO on the native functions.
In case you missed it, there was a good explanation of the choice not to do so, at least in regards to the Wait functions: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Wait-ms-with-error-pass-through/idc-p/2772856#M26878
I think this is an easy rule that many don't follow: If something can't, and never will, act on an error or create an error, the error wire has no place in the code. The "and never will" becomes more important with objects/dynamic dispatch but is otherwise an easy enough rule to follow.
I hadn't seen the discussion, but I can sum it up in two letters:
B and S
I can't say I agree with (m)any of the things that aristos posted on the idea exchange, but I've never once gotten the impression that he was BSing people.
As for the idea itself, I personally argue against it. LabVIEW should be a language. Adding a sequence structure and a few wires to a VI is not a language feature.
It's a primitive. There is no wires nor sequence structure in a primitive.
This is one of those that NI and I are just going to have to agree to disagree. When I see every company out there have a wait function in their library just so they can sequence the wait with the error cluster, that tells me there is something wrong with the core language.