Embedded Error Case Frame Option

[whyDoINeedAnAliasDamnIt]

Writing good code typically involves spending a lot of time coding up error handling cases.

Dropping error cases around enumerated or string controlled cases is a common structure task.

This takes up quite a bit of diagram space and coding time when integrated over the entire job.

If an enumerated or string controlled case structure could have an optional terminal dedicated for the error data type only, this structure could be more efficient to code.

A typical implementation looks like this:

My proposed structure would look like this:

Cheers.

Ray M.

[tst]

There are already a number of similar ideas. Read those discussions.

Here are a couple of examples:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Multiple-Case-Selectors/idi-p/1301780

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Multiple-Case-Selectors-along-with-shared-not-se...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Multi-input-in-case-structure/idi-p/2987215

[Darren]

Duplicate of http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Multiple-Case-Selectors/idi-p/1301780

[whyDoINeedAnAliasDamnIt]

I disagree that this is a duplicate of "Multiple Case Selector"

Multiple Case Selector is problematic in that it requires a priority protocol of some sort.

My proposal always gives priority to the Error input.

It's a regular polymorphic case structure except with a special case for errors.

Very simple logic paradigm and quite useful for error trapping tasks.

[AristosQueue (NI)]

> Multiple Case Selector is problematic in that it requires a priority protocol of some sort.

Yours is a duplicate insofar as it proposes one possible way to resolve the priority protocol. If we were going to explore any variation along these lines, the whole conversation about multiple ? terminals would have to be held.