Error Cluster Wiring - Styles?

[zenthoef]

Maybe I'm just splitting hairs here, but... There has been a bit of debate around my work about wiring error cluster wires through things like property nodes and VISA close sessions. 

Some people prefer to wire error lines like in the attached file "Disconnected Error Wires.png". They claim the pros are: 

1. If an error occurs, you may still want the property node to execute, and this setup guarantees the property node will execute.

2. If an error occurs, you can still close the VISA session and not have a memory leak.

The proponents of this setup don't discuses cons, but to me, the major con is not using what NI has provided us to enforce data flow. Besides enforcing dataflow, there is no way to capture errors from the items that aren't connected (assuming this example used error handling). Also, when you end up with a lot of property nodes wired up loosely, all over the block diagram it becomes hard to read, imho. 

I have generally been wiring things like in Connected Error Wires.png. I do understand that in this case the property node won't always execute if there is an error. In the instances I care about property nodes executing if there is an error, I'll do something like in Retain Errors.png. Usually, I have my VISA close in an EXIT state. Errors don't come into that state because I use a state machine that always reports errors right away and does not pass them to other states, so basically I make sure errors don't get fed into the VISA Close vi.

All that being said, I think its superior to always use the error cluster wire as provided by NI, because you can still execute property nodes and VISA vis, even if there is an error, with some clever programming. 

So what I really want to know is: what is your opinion? Is it always so critical to catch errors or is it okay to not hook the error cluster up in instances like Disconnected Error Wires.png"? 

Thanks!

[RavensFan]

VISA close is one of those functions that will still execute even if an error is fed into it.

I don't think it's a particular problem not wiring up the error wires on something like a Value property node.  I don't expect there to be any reason for the Value property node the way it is used to ever throw an error.

I think one problem you have in all of your images is when you use a shift register for the error wire, especially if you don't do anything to explicitly handle and clear an error.  On any given loop iteration, it would not be that unusual or unlikely that you'd get an error such as a timeout on a VISA read.  But if you did, the error would get passed to the next iteration of the loop preventing your VI from ever executing a VISA read again.  Would you want a pretty benign error such as a VISA timeout to completely kill the functionality of your program?

[zenthoef]

---

I think one problem you have in all of your images is when you use a shift register for the error wire, especially if you don't do anything to explicitly handle and clear an error.  On any given loop iteration, it would not be that unusual or unlikely that you'd get an error such as a timeout on a VISA read.  But if you did, the error would get passed to the next iteration of the loop preventing your VI from ever executing a VISA read again.  Would you want a pretty benign error such as a VISA timeout to completely kill the functionality of your program?

---

That is true, you wouldn't want that. I was just trying to make a simple example. If I had coded this into a state machine, I'd pass the error around the shift register, birng up the error case, handle, log, and clear the error. If it was just a SubVI I'd probably exit the SubVI on an error and go to the Error state. 

[zenthoef]

---

@Ravens Fan wrote:

VISA close is one of those functions that will still execute even if an error is fed into it.

---

I see this from the LabVIEW help now. But it makes me wonder... Is there a list somewhere of all the LabVIEW built stuff that will function normally even if an error occurred before a that item runs?

[zenthoef]

---

@zenthoef wrote:

---

@Ravens Fan wrote:

VISA close is one of those functions that will still execute even if an error is fed into it.

---

I see this from the LabVIEW help now. But it makes me wonder... Is there a list somewhere of all the LabVIEW built stuff that will function normally even if an error occurred before a that item runs?

---

I poked around this morning looking for other nodes that will still execute properly if an error has occurred before they run. It seems like a lot of the things that close a refernce do run normally even if an error has occurred (Close File, Close Registry Key, DAQmx Clear Task). It makes sense to allow these nodes to run even if there is an error before them because it prevents those references from staying open and creating memory leaks.

So my new question is: Is there anything else that makes sense to run even if an error occurs before it? The only thing I can think of are these things that close references. 

[RavensFan]

I'm not sure I've ever seen a comprehensive list.  But yes, in general anything that closes or clears runs even with an error coming in.

Oh, and the Clear Error VI also always works when an error comes in.

[zenthoef]

---

@Ravens Fan wrote:

I'm not sure I've ever seen a comprehensive list.  But yes, in general anything that closes or clears runs even with an error coming in.

Oh, and the Clear Error VI also always works when an error comes in.

---

LOL. I'd hope it does or else that would be very pointless! 

[carlos_camargo]

---

@RavensFan wrote:

...On any given loop iteration, it would not be that unusual or unlikely that you'd get an error such as a timeout on a VISA read.  But if you did, the error would get passed to the next iteration of the loop preventing your VI from ever executing a VISA read again.  Would you want a pretty benign error such as a VISA timeout to completely kill the functionality of your program?

---

I would.  I might be statusing something important and if the response is not forthcoming, I need to know that I am dealing with old data or that maybe my instrument isn't there anymore, maybe never even was.  Oftentimes with VISA, writes go along happily writing to non-existent instruments and it is only at reading time that you realize that oops! the instrument isn't even present (could be at the wrong address...).  Probably using the locator VIs would preclude this kind of error but... I think I went off on a tangent. 

I'll say this, I always want my error to flow everywhere and through everything.  If there are errors that I want to ignore for a specific reason, as in for example, the user cancelled on a file selection dialog, then I insert the "Erase Error" function with a specific error number to erase if it matches.  I know what error to expect because I test what happens under specific circumstances.  I think that meticulous error handling is fundamentally important not just in LabVIEW but in any language.  It is important for code maintenance as well as for assisting users who are not programmers.  It helps them to help us help them.

[RavensFan]

Pretty old message thread to reply into.  But your message actually agrees with my point, and not disagrees.

I said you don't want a benign error to kill your program.  You said you would, but then proceed to say how you implement property handling to do something or clear that error.  So you are actually handling an error properly rather than just allowing it to kill your program.

[carlos_camargo]

Yes, I agree that we sort of agree.  I only disagreed with characterizing a VISA timeout error as bening given that it often isn't per my diatribe/explanation. 🙂

We also agree on this being an old thread but it somehow floated up for me, not sure why...