LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
Petru_Tarabuta

Wiring LabVIEW error to structure input tunnel should not clear the error

Status: New

Problem: Currently wiring an error wire to a structure input tunnel that does not continue as a wire clears the error that exists on the wire.

 

Happy case: When running the VI shown below, Automatic Error Handling correctly detects that the error out terminal of Error Cluster From Error Code.vi is unwired, and handles the error (displays the error as a dialogue window).

2 (edited).png

 

 

 

 

 

 

 

 

 

 

Unhappy case: Wiring the error wire from the error out terminal of Error Cluster From Error Code.vi to a structure input tunnel clears the error. Automatic Error Handling does not detect or handle the error.

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

In my opinion this was simply an unfortunate design decision (can happen to all of us) back when it was made, decades ago. IMO there is no logical argument to support this behaviour. The fact that the error wire is wired to an input tunnel does not mean that the error was handled. At best, when a programmer intentionally used this technique, it represents a non-self-documenting coding practice (why not use the self-documenting Clear Errors.vi?). At worst, it means clearing errors simply because the programmer forgot to wire the wire through the structure. It means clearing errors when the programmer did not explicitly ask for this. It means "sweeping errors under the carpet", and can result in overly "optimistic" applications (apps that seemingly execute without error when in fact unhandled errors are being generated).

 

Please note that even though the screenshot above shows a Flat Sequence Structure input tunnel, the behaviour applies to every structure (case structure, for loop, while loop, etc).

 

To summarise, the problem is that the screenshot above is functionally equivalent to explicitly using the Clear Errors.vi, as seen below.

4 (edited).png

 

 

 

 

 

 

 

 

 

 

 

Clear Errors.vi is of course the self-documenting, recommend method of clearing errors. It should also be the only method of clearing errors.

 

Ironically, Clear Errors.vi itself uses the "clear error by wiring it to input tunnel" technique inside its "0" case, as seen below.

5 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

To its credit, Clear Errors.vi uses a correct technique for clearing errors inside its other, default case.

6 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Another example found "in the wild" of a VI using the "clear error by wiring it to input tunnel" technique. This VI ships with LabVIEW and is found at <LabVIEW installation folder>\vi.lib\Utility\EditLVProj\Identify VIs Among Project Items.vi.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Solution: Disable the "clear error by wiring it to input tunnel" behaviour. This would fix what IMO is an incorrect design decision. Unfortunately, fixing this decision now would result in VIs that use the "clear error by wiring it to input tunnel" technique to start throwing unhandled errors if AEH is enabled. This is not ideal, but it might be worth accepting this short-term drawback for long-term gain.

 

Moreover, it may be useful to introduce a Clear Errors node (primitive function). The Clear Errors.vi could then make use of the Clear Errors node inside both of its cases. Alternatively, the Clear Errors node could simply replace and supersede the Clear Errors.vi.

7 Comments
LV_Tim
Member

This is a bad idea:

Firstly as soon as you wire an error output the software is expecting you are going to do something with it and so not generate an error dialog. (In you example you connect a terminal to a sequence structure, this is doing something with an error output and you are explicitly not doing anything with it so no error dialog appears).

Secondly relying on the build in error dialog is generally bad practice for larger projects. Error management is an important part of the software architecture.

OneOfTheDans
Active Participant

I believe dead-ending Errors into empty structures long predates Clear Errors existing (to answer your question "why not use the...").

 

Automatic Error Handling is a kludge, so I disagree that this semantic fix is worth breaking over a decade of barely maintained code (think of all the IDNet drivers from companies that don't even exist anymore).

Petru_Tarabuta
Active Participant

In reply to LV_Tim:

"This is a bad idea: Firstly as soon as you wire an error output the software is expecting you are going to do something with it and so not generate an error dialog. (In you example you connect a terminal to a sequence structure, this is doing something with an error output and you are explicitly not doing anything with it so no error dialog appears)." - Don't you see a problem with the error disappearing simply because it was wired to an input tunnel (that is itself unwired downstream)? Why should the error be cleared? Why is this a useful programming construct? Where did the error "go" to? The error reaches a dead end and then vanishes. It is an anti-pattern.

 

"Secondly relying on the build in error dialog is generally bad practice for larger projects. Error management is an important part of the software architecture." - Perhaps read the post again and show where I argued in favour of relying on the built-in error dialogue (you probably mean Automatic Error Handling). I wrote "When running the VI shown below, Automatic Error Handling correctly detects that the error out terminal of Error Cluster From Error Code.vi is unwired, and handles the error (displays the error as a dialogue window)." This explains that the error does not vanish in the first screenshot, which is the correct, desired behaviour (we don't want errors to vanish).

 

Of course error management is an important part of software architecture. I created a free, open-source Global Error Handler module - named the Error Manager - available on VIPM, which does not solve all of one's worries about error management, but is a step in the right direction.

 

In reply to OneOfTheDans:

"I believe dead-ending Errors into empty structures long predates Clear Errors existing (to answer your question "why not use the...")." - Thanks. That makes sense.

 

"Automatic Error Handling is a kludge, so I disagree that this semantic fix is worth breaking over a decade of barely maintained code (think of all the IDNet drivers from companies that don't even exist anymore)." - I disagree that AEH is a kludge (as I've already made clear in my comments to this and this, so won't dwell on it here again, haha), but I agree that the semantic fix (I'm glad you see it as a semantic fix too) probably is not worth implementing due to, like you say, the large amounts of barely maintained code.

 

I think this is a clear and interesting example of how difficult it can be to change something that is clearly suboptimal, but that has been around for a very long time - as applies to engineering or even society in general, not just to LabVIEW or to programming languages. Philosophical question: The longer something exists, the less likely it is to be changed?

wiebe@CARYA
Knight of NI

>Philosophical question: The longer something exists, the less likely it is to be changed?

 

See the Lindy effect - Wikipedia

Petru_Tarabuta
Active Participant

Thanks! Learned something.

fefepeto_kb
Member

Just to get every perspective documented in one place, here is a connected, not resolved conflict among developers:

The error wire shall never be used to enforce dataflow.

I think it's connected, because wiring the error to a structure then not using the values is most of the times achieving this goal.

The debate is unsettled, because using the error wire to enforce dataflow is an undesirable practice, but to date this is the most universal solution to that problem.

Why it's important here?

Synchronization is solved many times by just adding flat structures on diagrams, for code that has 0 dependency on the rest of the data, but has to be executed at a given point in the execution. Adding error wires would make to code access more data than required. Then it shall be in-lined, to work around our work around. Most of the times these mechanisms depend on the error wire. Adding clear errors for each branch to avoid error dialogs or expecting the IDE to automatically detect that it is only a branch of the wire is unrealistic for me.

wiebe@CARYA
Knight of NI

I use the class wires to synchronize.

 

If a VI doesn't skip anything on error, or can generate an error, it doesn't get error in\out.

 

If a method doesn't change a value AND never needs synchronization, it doesn't get a class output.