Drop sequence structure and promote to use modified error wires to impose the flow.

[MimiKLM]

I don't know if this idea has appeared before, but for me it looks interesting enough to be presented even again.

Now the sequence structure takes a lot of place in the block diagram.

Why not utilise modified error wire to impose the flow instead? The modification would be that potential errors transmitted over this wire would be ignored, if a proper option on the error wire (or in VI or in the environment) will be selected; for example: impose flow only or ignore the errors.

I'm aware that the proposition of an option of automated ignoring the errors in error wire doesn't sound good. I agree that there is a good practice that error should be rather displayed and captured quickly than ignored and forgotten. And I'm aware that developers can explicitly break the error wire within the VI which effectively do the job: impose the flow with ignoring errors.

However, the reason of  this proposal is to speed up the code development based on the native LV paradigm of the dataflow. It would be much quicker to build the application in quick and dirty style by not introducing the space consuming structures as the sequence structure is (BTW: I'd still recommend to leave the stacked sequence structure) and spending the time dedicated for development and solving real world problems for trying to fit and extend the structure and VIs within and around it.

For me ignoring the errors on the error wire option would be a natural option. Maybe a bit semantic should be involved here as well for better naming and description, but I think the idea is good enough to be presented.

[Intaris]

1. Not all primitives or sub-VIs have error inputs

2. Having an error cluster on the FP costs a little bit of execution time.  It's not always desired

3. You can place a "clear errors" on any error wire you like.

Perhaps most importantly.

4. This is already pretty much standard coding practice.

[MimiKLM]

Ad1 & ad2:

that is fine. if no error cluster then there is no case. The flow will be imposed by the other wires.

Ad3:

which is essentialy what I've said above about breaking wires.

Ad4:

What do you menan? Using sequence structure is a standard coding practice? Or using errors wires is a standard coding practice?

[Intaris]

Using wires to force program flow is standard practice.  I see no benefit of over-complicating the error wire (which for reasons I have mentioned is not always fit for the job) over simply applying standard practice of using wires to determine execution order.

While I am certainly no fan of the sequence structure, it's there for dictating order when wire flow isn't really possible (VIs with no input wires for example)..

Your proposal doesn't improve on the current situation.  as far as I can see.

[MimiKLM]

Yes, so if the using wires is the common practice, then my proposal is not against the paradigm. It's rather promoting the the good practice in lat say "a natural way", rather than using structures to secure the flow.

Having a VIs without a input (or input and output) wires is a bit against the LabVIEW logic (I'm still reffering the to the dataflow paradigm) because you have to have a wire to program in LV. Of course we can have the situation when the developer uses only sequence structire to enforce the flow, but I think we can agree that is not the way the NI wants the developers to use LV.

My idea is about change the optics a bit. Why not to enforce a bit using the wires rather than giving the oppportunity to overuse and missuse the sequence structure?

What if we can think about the error wire as a flow control wire with error carrying funcionality?

[Intaris]

What if we can think about the error wire as a flow control wire with error carrying functionality?

That is what is already IS and has been for a long time.  Hence I don't see how your proposal actually changes any of that.

Again, while I think the sequence is overused at times, it DOES have its place at times.

[MimiKLM]

Ups, it looks like I've forgotten to add "optional" word. The sentence should be:

What if we can think about the error wire as a flow control wire with optional error carrying functionality?

I'm sorry for the mess.

What I want is to have the ability to optionally disable error passing.

K.

[Intaris]

You can already do this with the tools available.  "Clear Errors" between nodes will do exactly this for you.

[MimiKLM]

Which double the number of VIs. I don't want this.

I'd brefer to have an option not to carry errors from VI to VI, but still have the error wire (flow wire).

[jcarmody]

Let the Kudos fly!

[crossrulz]

Sounds like a duplicate of this idea:"Sequence Containers" to force execution flow without data dependancies