Standard marking for when 'error in' is ignored/passed through

[matt.baker]

Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.

I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.

Examples: Release Semaphore, Close reference, Release Notifier

Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.

Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):

[LukeASomers]

The lower left one with the disconnected error out is a really bad idea, since you can lose actual upstream errors that way

[AristosQueue (NI)]

LukeASomers: Sure, but that's a different issue than what matt.baker is trying to cover. If a VI is written without propagating the error then it should be marked as executing regardless.

matt.baker: I agree with you. I've long wanted a better syntax for all of this in LabVIEW. This one frustrates me because I see G programmers fight with this all the time, but I can't get R&D traction to do much about it because when asked directly about it, most say it isn't a big deal for them to read the CH and figure things out... in my observation, they underestimate the amount of time lost to this issue, but because they downplay it, it gets continually deprioritized. This idea gets my kudos.

[JW-JnJ]

I love this idea. LabVIEW is a language that you need to debug and understand by visually scanning over a field of icons. Anything that gives me an idea of what's happening at a glance is great in my book. This would be doubly helpful for native VIs and locked VIs that you can't see the code for.

Block diagram would be a readily visible way to indicate this. However, I'm torn on this due to visual clutter.

If the block diagram would be too polluted by adding a visual indicator, I would suggest adding a visual indication to the context help window. Maybe a red or green dot next to the error input (just throwing it out there, not set on this). In addition, letting coders turn this indication on/off per VI would solve the problem for locked VIs.

[matt.baker]

Would definitely want something in the context help.

For the block diagram view, maybe something similar to these may work. Although with these you lose ~22% of your icon real estate.

Maybe a border coulour would be better?