'Run Even If Error' option for nodes

[SteenSchmidt]

Hi.

Most nodes in LabVIEW have what is coined 'standard error in functionality', which basically means the node is skipped if an error is present on its error in terminal - like this Defer Panel Updates property node below:

A smaller subset of nodes behave differently if an error is present, usually by running anyway which is the case for the Close Reference primitive for instance.

Sometimes it's desirable to run one of these nodes with standard error in functionality also in case of error, and then one has to resort to something like this clearing the error before the node and bundling the error wires afterwards to maintain dataflow priority:

I suggest a new Run Even If Error option for property and invoke nodes, similar to the Ignore Errors Inside Node option in the context menu:

This could be expanded to other nodes/functions/primitives as well...

...but this time around I'm only suggesting this for property and invoke nodes as that may hit fewer obstacles.

Cheers,

Steen

[fabric]

I like the idea.

And for the record, I'd also like to see this extended to *all* VIs. Yes... I know this might seem a bit radical for some, but (regardless of your views) "standard error in functionality" is so fundamental that I see no reason that it should not be formalised a little more. Specifically, I'd like to see support for virtual error terminals (if none are defined) which allow modes such as "Standard", "Run Even If Error"... but that's probably another conversation!  

I've long thought there should be a property for "Run Even If Error"... It would help to facilitate this popular idea: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Visual-indication-that-VI-will-run-even-on-error/idi-p...

[Brandyn]

This is an interesting idea and I do not know how I feel about this.  One challenge I have with this is that error wires are there for a reason and you would not want specific things running if there is an error.  So the question I have is, would this functionality only be in place for development? Or this would be in  permanently? What if it can be done on specific functions and you can control it just like you control a conditional disable structure?

[SteenSchmidt]

@Brandyn: Sure the error wires are there for a reason, but sometimes the deafult behavior is not wanted. I'm just suggesting a simpler way to defeat the default skip-on-error behavior in these situations.

I'm not discussing if such situations arise, because it's a fact that they do (at least for me ). Consider my example in the idea itself; If you defer panel updates and then an error occurs, it will often be crucial that the GUI is released again by clearing the defer panel updates property at the end of the error wire. By default, if you just serially wired the error terminals, the FP would remain locked for user input since the DPU property node skips-on-error as the node behaves independently to which property is being set. I'd just like a cleaner way to configure certain nodes for non-default behavior, instead of having to code the shown workaround.

I'm not suggesting any node should overwrite the incoming contents of the error wire, mind you, I just want to tell the node to execute anyway in case of error.

/Steen

[SteenSchmidt]

@fabric: I don't see my connection to the LAVA thread you posted a link to? An interesting discussion on its own, but I had no part of it.

I'm not a fan of such an option being available on all user subVIs. I think it'd be misused. As Stephen points out there are many good cases where a subVI shouldn't apply more error handling than the code it consists of does already. So a possibility for a user of that subVI to indiscriminately, without even looking at the subVI code, add some extra code to the subVI (by right-clicking and setting 'Run Even If Error') will certainly be non-optimal. We already have the necessary control over subVIs to define their error-handling, but that fine control lacks for built-in nodes - especially such generic nodes as the property and invoke nodes.

/Steen

[fabric]

"I don't see my connection to the LAVA thread you posted a link to?"

I just included it because it is one of the better discussions on error handling that I have come across. It was intended to give some context to the "all VIs" argument... that's all.

"... I think it'd be misused ... a possibility for a user of that subVI to indiscriminately, without even looking at the subVI code, add some extra code to the subVI (by right-clicking and setting 'Run Even If Error') will certainly be non-optimal."

Error terminals are already misused!  If standard error handling were available as a selectable option, then changing to "Run Even If Error" could potentially improve performance by avoiding a comparison. My thought process goes something like: "If error handling were native, then it could likely be better optimised." 

[SteenSchmidt]

Even if something's misused it's no incentive to keep adding mis-usable options .

Ok, so you're basically suggesting that error handling as we know it should be removed from the subVI BD and moved into a configuration parameter on the subVI? Or at least the addition of the two mutually exclusive options 'Run Even If Error' vs. 'Run Only If No Error'. It's certainly a possibility, but I can still see quite a steep learning curve ahead, when we all need to relearn what we are no longer supposed to do with the error wire inside the subVI. I'm afraid that such an option would obfuscate the net error handling behavior.

But I'm open to the discussion at least. Sometimes there are bigger benefits in radical changes vs. incremental ones. Or there could be valuable, less radical, spinoff from the discussion itself.

/Steen

[JB]

The suggested visual indication should be changed because of its similarity with the one of the existing "Ignore Errors inside Node" option.

[SteenSchmidt]

@JB: The Ignore Errors inside Node glyph is on the error out terminal, while I suggest this new Run Even If Error option highlights the error in terminal. I think even for the Ignore Errors inside Node feature the ?! glyph doesn't convey more than simply "Beware! Something out of the ordinary is happening with this error terminal.". Therefore I think it could be used on the other error terminal as well, just for a different configuration. Both modifiers could potentially be enabled at the same time on a node, yielding ?! on both error terminals.

/Steen

[GregFreeman]

See this idea I posted, expecially the responses from AQ at the bottom of the comments. I think these types of things are good ideas that developers identify with, but it's determining a good way to implement them that is the problem.

[SteenSchmidt]

@for(imstuck): I agree that finding a good way to implement ideas can be a challenge, but that is exactly what this discussion board is about. And in this particular case I think the idea has been cut out pretty solidly. Broadening the idea to include all built-in primitives is pretty straightforward as well, while the user created subVI case is much harder. The latter would probably entail some kind of rewrite of the entire way we define and implement error handling in VIs.

Cheers,

Steen