Stall Data Flow should be a no-op in the event of an error

[croohcifer]

I'm a huge fan of the Stall Data Flow malleable VI except in the case that I have it wired on an error wire (my most common use case) and there's an error on the wire.  I generally trust and expect that VIs (especially those on the palettes) will no-op (with rare exceptions like close ref methods) and fail fast in the event of an error on the error in terminal.  I understand that this is kind of a unique case since the VI in question is malleable and doesn't have an actual error in terminal, but my guess is that most users:

1.  Wire this specific VIM on error wires most often

2.  Likely don't want the VI to stall in the event of an error

3.  Would prefer to see that error propagated as quickly as possible like most other VIs do

Thoughts?

[AristosQueue (NI)]

It doesn't have error terminals. It has data that happens to be an error terminal. It cannot itself produce errors.

The Variant To Data node takes in a default value and outputs the converted value. If I wire an error cluster to the default value, would you expect the node to skip its behavior? I hope not. Sometimes errors are just data. And that applies to your point...

> I was always taught that code should bubble up an error as fast as possible, so I code

> with the mindset that if a VI has error terminals, it should propagate any incoming errors

> (i.e., status boolean = TRUE) as fast as possible regardless of whether the VI itself can

> contribute an error to the error chain.

This is often true but not always. It is not true if the code is an error handler. It is not true if the code is a log processor. Consider the case where I have a scrolling display to user. I read a stream of errors from my log and I send them to the scroll display at some rate -- I stall each one by 1 second. This isn't a contrived example -- I've actually written systems like that.

Not all errors are *errors*. If they're just data, they should be handled as data. The Stall Data Flow stalls *data*. It is blind to the data's contents. In my opinion, if you want to change the dataflow based on the value of the error, drop a case structure and skip the node on error. It would be extremely counterintuitive to me to have that node suddenly develop special behavior based on the type of the data wired.

[kosist90]

For this, you could try OpenG Time pallete - it has Wait (ms) function, which has flag to skip wait in case of error.