Should Error-Driven Case Structures be Used in Every VI?
By Andrei Zagorodni
The most used VI template is probably SubVI with Error Handling.
It can be seen everywhere starting from a beginner’s two-VI program to the most complicated pieces of software. But is it as necessary as we think?
A Case Structure is used if different code should be executed depending on the value provided to the Case Selector. An error-driven case structure allows executing different code depending on the presence or absence of an error:
However, in most of the cases the error case is left empty. Thus, purpose of such case structure is skipping execution of the code.
What happens if we remove the case structure?
Probably nothing happens because each subVI has its own error-driven case structure. Even if not, attempting to execute could probably do no harm.
What does the case structure do if there is no danger in executing SUB1, SUB2, and SUB3? It only speeds up the execution if an error happens. But how often do we care about speed of execution if the program is running in an error state?
Unnecessary use of error-driven case structures optimizes execution in error state and de-optimizes execution in normal state. Is this what we want to be doing?
However, error-driven case structures are very convenient in the debugging process. Let’s put our VI in a loop:
Let’s assume that one of the subVIs (SUB1, SUB2, or SUB3) launches an error. Which one? This could be answered by turning on Retain Wire Values and running the program.
However, an error generated in a previous iteration will propagate to next iteration, making retained values useless.
But, if an error-driven case structure is involved, the error-causing subVI can easily identified:
Conclusions:
Think through the effect of using an error-driven case structure and only use one if it is necessary.
Remove some of error-driven case structures after debugging if they are not needed.