Understanding a sub vi's error handling at a glance?

[Daklu]

I know LV style guidelines and conventional wisdom states that sub vis should always have error in and error out terminals as a way to enforce data flow if it is needed. I found that without some insight into the sub vi's error handling I tend to wire them all up and impose an artificial data flow on my application. Sometimes I ended up going to great lengths to reorganize a vi so the error wire was clean when in fact the sub vis I was connecting weren't significantly affected by the error in terminal and didn't generate an error on their own that needed to be caught. I started removing the error terminals if it was simply passed through the sub vi, but I didn't really like that solution either.

I've played around with various combinations of settings for the error in and error out terminals and documenting error behavior ("This vi runs normally regardless of the error in condition.") in the properties dialog box but couldn't find anything that was simple/intuitive enough to use yet expressive enough to describe the most common situations. Recently I came up with this idea based on setting the terminal's connection property:

error in terminal - Not all sub vis case out the error in terminal and so the input value is irrelevant.

Recommended - The sub vi's output depends on the error in condition.

Optional - The sub vi runs normally regardless of the error in condition.

error out terminal - Not all sub vis generate errors so the error out terminal is irrelevant.

Recommended - The vi (or one of its sub vis) may change the value on the error wire, either setting an error or clearing an error.

Optional - The error out terminal value is always equal to the error in terminal value.

Using this scheme the error terminals on most typical sub vis would be Rec/Opt. Sub vis that do I/O or generate internal errors would be Rec/Rec. Close Reference sub vis would be Opt/Rec. My class accessor vis would be Opt/Opt since I set the new value regardless of the error terminal.

Thoughts? Is this a reasonably clear way to convey basic error handling information to the user?

[asbo]

I haven't used the scheme you came up with before, but I really like it. The only downside I can see is that without the context help open, you lose visibility. Even then, you'd have to mouse over each VI to check the terminal requirements. If you're just eye-balling a block diagram, especially a big one, that can be a bit unwieldy.

In the past, I've followed NI's example of Invoke/Property Nodes and added a little red "?!" to the icon if my subVI is going to ignore error.

There's no option to ignore incoming error, but obviously you can do whatever you want with your own subVI.

[Daklu]

The only downside I can see is that without the context help open, you lose visibility.

True. I almost always have the context window open anyway but I'm probably in the minority. I use it so much I remapped F1 to toggle the context window.

In the past, I've followed NI's example of Invoke/Property Nodes and added a little red "?!" to the icon if my subVI is going to ignore error.

I do recall seeing that icon a few times but to be honest I never paid much attention to it. I don't know that I've ever used that option on property nodes. My proposal is restricted to only 2 states: recommended or optional. Your solution allows for a much more expressive way of communicating error handling by creating different colored ornaments.

Thanks for the tip!

[Grampa_of_Oliva_n_Eden]

I haven't used the scheme you came up with before, but I really like it. The only downside I can see is that without the context help open, you lose visibility. Even then, you'd have to mouse over each VI to check the terminal requirements. If you're just eye-balling a block diagram, especially a big one, that can be a bit unwieldy.

In the past, I've followed NI's example of Invoke/Property Nodes and added a little red "?!" to the icon if my subVI is going to ignore error.

There's no option to ignore incoming error, but obviously you can do whatever you want with your own subVI.

Rep = rep + 1 for both for asking and answering.

Thanks for letting me eaves drop,

Ben

[asbo]

Since I'm a hair color-blind, sometimes I can't easily discern the different between the black and the red anyway (especially on the property nodes), so I eagerly await the day we can have animated icons

[Daklu]

I eagerly await the day we can have animated icons

THAT would make for some interesting block diagrams...

I'll be thrilled when we finally get more than 256 colors we can use.

[Yair]

I eagerly await the day we can have animated icons

You need wait no longer.

Animated Icon.llb

[jgcode]

Asbo I like your style!

FWIW I always use and always wire through the error terminals .

Because I am of the opinion that I never know in the future if they will be needed, and if they are then all the work is already done.

Edge cases is if I am really, really sure (normally for reuse functions).

I like what you have done as I like the fact that if the error in is not currently used, but I can give the developer a visual indication of this on the BD.

In the future if error handling changes I just update the icon, but the connector pane and how its wired does not have to changes - that seems quite safe to me.

[Daklu]

Asbo I like your style!

So throw him a kudo!

Geez, what a Scrooge...

[jcarmody]

 Since I'm a hair color-blind, [...]

How about your avitar?  Can it see colors?  If not, it's a color-blind hare (with a pancake on it's head).  

[jgcode]

So throw him a kudo!

Geez, what a Scrooge...

SORRY!

It was late when I posted, and I was excited just to be back on LAVA and I forgot... [running out of excuses...]

Done now tho

[Daklu]

Taken straight out of the "nobody cares but me but I'll bore y'all with it anyway" book, I tried asbo's suggestion of using the '?!' symbol to indicate error handling. I found that they took up too much room and made my icons, well... ugly. The idea is a good one though, so I just recycled some adornments I used in the past for specifying accessors and had discarded as unnecessary.

A green flag over the error in terminal tells me wiring this terminal is optional. In other words, having an error on the wire doesn't affect the vi's execution. If the flag is missing, then I know something in the sub vi will behave differently when an error is input. A green flag over the error out terminal tells me wiring this terminal is optional. In other words, the error out terminal is simply a copy of the error in terminal--this sub vi will not generate its own errors. If the flag is missing then the sub vi may raise an error. I also have red flags if there's something really unusual about the way a sub vi handles errors. I've only used it on the error out terminal for a couple vis that clear the error from the error in terminal and always send 'no error' on the output terminal. Red and green are about the worst colors I could pick for color blind people (sorry asbo) but they are the most distinctive colors on the palette.

Based on the combination of flags on a sub vi I know at a glance when I can skip connecting the error terminals. It also the unexpected benefit that I am becoming more willing to not wrap every sub vi in an error structure.

[Black Pearl]

I have some vi's that send the error on my global event bus and then clear the error wire. I like the error wire to determin by data flow when all modules finished execution and I can use the Quit LV prim.

These terminals are labled as "error out (cleared)" or "error out (no error)".

So my personal reaction would be to lable them "error in (ignored)".

Felix

[JackHamilton]

Be cautious when "Always" wiring the Error In cluster as a rule. Most functions will NOT execute on an input error. This can make error recovery fail, such as Closing a Reference...the Close will NOT execute if the input error = TRUE.

In general I do NOT wire the error inputs of : Enqueue operations, Init Ports, Close references...

[Yair]

the Close will NOT execute if the input error = TRUE.

I'm not sure where you got that idea. Most closing primitives work even if there is an error coming in, as is explicitly stated in their help (see the error in section). I believe that there are a couple of exceptions to this rule, but I don't remember what they are offhand.

[crossrulz]

I'm not sure where you got that idea. Most closing primitives work even if there is an error coming in, as is explicitly stated in their help (see the error in section). I believe that there are a couple of exceptions to this rule, but I don't remember what they are offhand.

Darren explains them fairly well in one of his weekly nuggets.