Unwired output of "Bundle" and "Bundle By Name" should show broken arrow

[Samuel_James]

If the output terminal of "Bundle" or "Bundle By Name" is unwired the vi should should show broken arrow.

You can ask me the question why?

Consider a scenario of the below picture. As soon I wire all the input terminals and input cluster of "Bundle By Name" the vi is in run mode. There is nothing wrong in that, But if I forget to wire the output terminal of bundle by name...... You know what will happen. If it happens in a sub vi of a very big project it is very hard to debug, More over there is no use in any scenario to leave the output of the Bundle By Name unwired, 

In the above picture the vi is in run mode when unbundle by name output is unwired

In the above picture the vi shows broken arrow when "bundle by name" output is unwired

[RavensFan]

Then do you want all functions or nodes that don't have their output terminals wired to cause broken arrows as well?  What you are proposing is in contrast to the way all other LabVIEW functions work.

The broken or solid LabVIEW run button is intended to show the programmer any syntactical errors.  "This VI can't run because ...."   It is not intended to predict bugs a programmer is going to cause for himself because he forgot to do what he intended to do.

[Mr.Mike]

I think this would be best as a VI Analyzer test..i.e. check for unwired outputs for node with a single output.  Broken VIs are syntactically incorrect.  The example you showed is syntactically correct, just a bug.

[Albert.Geven]

It should be a warning, not a broken arrow.

It can be a serious warning even because it is at its best a nonsens function and can be removed by the compiler.

I even agree that it should be easier to spot than to buy a VI analyzer.

Everybody that has been bitten by such mistake would be glad if the compiler helped a bit better in such cases.

I'm sure that helping out in such cases is better for starting programmers than express vi's ever can be.

[X.]

This would be best handled by a more sophisticated Error/Warning window. Currently the only "Debugging" Options (where the option to turn warnings on is located) are:

- Show warnings in Error List dialog by default

- Prompt to investigate internal errors on startup

Some revamping of the warning options would be welcome (that is: creation of a list of warnings that the user could select to show or not show when the option above is checked)... you would then be able to only select this "bundle to nowhere" problem (or more generally "read connector connected to nothing").

My 2 cts.

[SteveChandler]

Sorry but there is no way anybody can write a compiler that can detect nonsense code. It is possible to check this particular type of nonsense but there are twelve million more things that would have to be checked for.

[AristosQueue (NI)]

Kudos for this idea! I have long wanted some concept of "required outputs," particularly for pure function nodes (i.e., nodes that have no side-effects and only exist to do some data manipulation, like Add or Concatenate). I've raised the idea before, and though some people like the idea, there's generally only excitement around the idea of making "error out" be a required terminal for those folks who really try to track all their errors (there is a VI Analyzer test to check for this). Wider support for required outputs would be great, I think. 

The example you showed is syntactically correct, just a bug. 

And compilers should prevent bugs. Correct syntax is whatever the compiler defines it to be.

As for this bit of pessimism:

"It is possible to check this particular type of nonsense but there are twelve million more things that would have to be checked for."

LV already does check for various types of nonsense. The correct statement is that there are twelve million more things that *could* be checked for. Checking for this one is a good thing, in my opinion, and not checking for the remaining 11,999,999 does not invalidate that. As the editor improves its ability to check for the others, they should be added too, IMHO.

In general, my opinion is that compiler errors are ALWAYS better than runtime errors or allowing pointless code.

[AristosQueue (NI)]

For the record, in my observation, compiler warnings are useless in all compilers I have ever seen on every development team I have ever worked with in every computer language. People either care about the warnings and so upgrade them to errors (assuming the compiler supports that option) or they don't care about warnings and turn them off entirely. Something that is only "Oh, it's critical but I only check it every once in a while" is useless. To me, VI Analyzer is a reasonable stop-gap measure for LV today, but honestly, its funcitonality needs to become a part of the type checking to have any real value to me as a developer day-to-day. If it is only something that gets run occassionally, that will tend to happen at the end of a release, and at that point, people will say, "Oh, that's not really affecting functionality, and we don't want to risk breaking something by fixing it now." And those issues build up over time, never really getting fixed.

Now, if VI Analyzer is run as part of a source-code-control check-in process (i.e., the SCC system you're using refuses to allow any check-in unless that check-in passes VI Analyzer), that improves its utility substantially in my book, but it leads to a lot of grumbling when you've spent hours getting code working and you go to submit the fix, and it takes you another day to fix all the issues that the check-in process finds that would've been easier to address had you been told about them as you were working... things like naming conventions of terminals that spread throughout the code as you create more subVIs, that would've been easier to fix if you'd fixed the name the first time you typed it. Note: LV does not have any feature to force VI Analyzer to run on files before allowing the check-in; that's something that you have to make a part of your particular SCC system, if your SCC program supports that sort of gate check.

[SteveChandler]

I can see your point. Checking for this one thing is a start. But an unconnected output should not break the run button. Maybe the code is still in development and I have not got to whatever the output is going to connect to. It might be kind of frustrating not to be able to test the part I already have. If the output is connected to a terminal but the terminal is unconnected would that break or count as connected? I might be ok if it didn't break in that case.

[SteveChandler]

I see this is getting some kudos. NI, please please PLEASE make this an option if you implement it!

[dthor]

As long as I have the option to enable/disable "Required Output" errors in the code, I'm fine with the idea. However, I all too often have nodes with no outputs while I'm writing / debugging code. You'll see various math that goes nowhere, unbundles into the void, and string contants just floating around while I'm getting code to work.

Of course, once it starts working, I go through and delete / disable the stuff I don't need. But If I have to put everything I'm not using into a disable structure just to run the program, I won't be happy.