"Function terminal not connected" detection (plus shameless plug for another pet-peeve of mine)

[X.]

Must have been discussed a zillion times, but just in case, there it goes:

what's wrong with this picture?

apparently nothing. If I grab the function and move it:

Note that LV must have "computed" something here to reroute the wires, etc.

But wait, what happens if I grab the wire and move it?

Oops! I did not connect the output of the function to the indicator. Instead, I inadvertently connected the input.

Needless to say, this is a F-ing nightmare to debug... unless you think of verifying that the value before the function and after the function actually gets incremented. Which you will, eventually, but not until after having wasted a lot of time thinking of all other possibilities elsewhere in the code.

Bottom line (this is only an example I just encountered for the umpteenth time a minute ago), LV does not provide much in terms of warning for this kind of potentially very damaging error. This is very much related to the discussion I started here with very limited success (man, am I an upbeat person!). 

Suggestion: not only allow to define VI outputs as REQUIRED but also add warnings when a function that has its only or most important output(s) unconnected.

And if not everybody is interested in this kind of sanity check (I am talking about functions), you could offer this "warning" as an option (in a warning definition panel in the Preferences).

[X.]

As a comment, LabVIEW supports "Recommended" and "Optional" outputs (at least in LV 2013).

"Recommended" is the default, but if you choose "Optional", the output name (in the contextual Help window) is grayed out (as it is for an "Optional" input).

What does this bring to the coder? I have no clue. But I'll take it as an indication that NI engineers have thought of (and implemented) different flavors of outputs.

[AristosQueue (NI)]

> LabVIEW supports "Recommended" and "Optional" outputs (at least in LV 2013).

At least as far back as LV 6.0. The use case for Optional is rarely used outputs that are "side effects" of the node's primary purpose that you don't want cluttering the discussion of a particular node when you document it in the Context Help. Sometimes useful for library/API development, not really useful for application development.

[X.]

I would for instance argue that the "data value reference" output of the New Data Value Reference would be a good candidate for a NI-imposed "required output", for the very reason explained in the help:

 

"Memory leakage might occur if you do not delete the reference".

Likewise, the "Data Value Reference Write Element" node probably should have a required "data value reference" output in order to not forget to delete that "data value reference".

Currently, this does not break a VI:

[jacemdom]

---

@AristosQueue (NI). wrote:

required outputs stir up a lot of frustration/anger from various parties. There's a pretty complete post of their objections written by Darin.K on the forums from a couple months ago (sorry, I don't have the link close at hand)

---

Would really like to obtain the link to those objections because i cannot figure out what is the problem with allowing required outputs on user VIs defaulted to recommended, and even adding an option to treat unconnected single output functions as errors defaulted to inactive. So no change to current behavior and possibility to step up code checking for those who need it.

[X.]

It is usually objections of the kind: "we don't need no stinkin' seatbelt or helmet". Sure. That is, until you are dead.

[jacemdom]

Considering that the change would default to current behavior, the argument then becomes "YOU don't need no stinkin' seatbelt or helmet"... sorry but due to my failure to be perfect I do need it.

[thols]

Channel wires are a newer candidate for when required outputs would be great. If I miss to connect a channel wire output, I have to run the application before I notice that. And when I run the application, it will halt (STOP!), which leaves references open and such things, and I have to reload the project. It does display a message, but it lacks a call chain so I only know that the error is anywhere in my application: