Automatic error handling

[1984]

Hi,

So far I always kept the Automatic Error Handling (AEH) on for my VIs. My thought process was that 

- IF I made an error in programming by not terminating all my error cluster

- AND an error occurs

- THEN I'd like to display it otherwise the error remains silent and I wont have an idea that it even occured

Today I have realized that the VI analyzer throws an error if I have the the AEH. That made me thinking but the only thing came to my mind is having a popup could be dangerous in some situation as it stops the VI execution. I still rather back having the AEH on cause yes it can drop a popup, but not having a popup keeps the error hidden and also could lead a potentially dangerous situation. If we are at the brink of a situation then I prefer to - at least - know about the error.

Could be that I missed something or I dont evaluate the risk properly so I'm wondering if there is a consenus about this subject. Do we need to use automatic error handling in our VIs, or should we turn it off? (forget RT for now which doesnt support it)

Thx.

[GerdW]

Hi 1984,

IMHO:

• Your program should handle any errors on its own. Never leave an error wire ending in the open wild…
• Even when you don't "handle" an error you should log that error: create a small "error log" subVI as a starter…

In my early LabVIEW days I was biten by such AEH dialogs as the remaining program might be blocked. That's why you should (IMHO) switch off the AEH once and for all!

[1984]

Thanks for responding. 

• Your program should handle any errors on its own. Never leave an error wire ending in the open wild…

---

True, but if we wire all the error outputs then my question doesnt make sense as in that case the AEH has no effect. My question is rather which one is the lesser evil. A popup which could lock your app or a possibly unnoticed error causing unexplainable problems? Now as I write it down, this seems more of an application specific decision.

• Even when you don't "handle" an error you should log that error: create a small "error log" subVI as a starter…

---

Absolutely, but thats again assumes that the programmer connects all the error clusters.

[GerdW]

Hi 1984,

---

@1984 wrote:

My question is rather which one is the lesser evil. A popup which could lock your app or a possibly unnoticed error causing unexplainable problems? Now as I write it down, this seems more of an application specific decision.

---

It's very app specific!

When you app "just" reads in some data files and does some number crunching then an error dialog like "file not found" may be appropriate. When the app controls a big testbench with several safety-related control loops then it might get problematic, when an error dialog blocks UI interaction…

---

@1984 wrote:

Absolutely, but thats again assumes that the programmer connects all the error clusters.

---

Yes, it's the programmer that is responsible for its work…

[billko]

One vote here for automatic error handling on during development is that it allows you to put probes on your wires.

[GerdW]

Hi Billko,

---

@billko wrote:

…automatic error handling on … allows you to put probes on your wires

---

Could you explain how using probes is related to AEH?

[billko]

I can't reproduce it in LV 2018, but I've seen in LV 2020 that if you have AEH turned off, your probes will say "No debug Info" and they won't work.  BUT, I only have one copy of LV 2020 and the code resides on a computer where I am not allowed to share code from.  In that environment, in order for probes to work, you have to enable AEH or they are just grayed out with "No debug info" where the probe data would normally be.  This consistent throughout all the VIs already made, and any future VIs that are made.

[Darren]

Automatic Error Handling should have no effect on probes. If you can reproduce the probe issue you describe, please give me detailed instructions on how to do so. I have used LabVIEW 2020 as my daily driver IDE for the past 2.5 years, I have AEH turned off on all my code, and I've never had a problem with probe functionality.

To reply to the OP, there is a contingent of LabVIEW programmers who feel that AEH is a crutch and hinders LabVIEW programmers from putting proper thought into the error propagation that takes place in their VIs. I fall into this camp, I added that VI Analyzer test, and AEH is one of the many topics I discuss in my What to Expect When You're Expecting an Error presentation: http://bit.ly/dnatterrors

If you don't agree, that's fine... just deselect the Auto Error Handling Enabled VI Analyzer test in your configuration.

[Mark_Yedinak]

---

@Darren wrote:

Automatic Error Handling should have no effect on probes. If you can reproduce the probe issue you describe, please give me detailed instructions on how to do so. I have used LabVIEW 2020 as my daily driver IDE for the past 2.5 years, I have AEH turned off on all my code, and I've never had a problem with probe functionality.

To reply to the OP, there is a contingent of LabVIEW programmers who feel that AEH is a crutch and hinders LabVIEW programmers from putting proper thought into the error propagation that takes place in their VIs. I fall into this camp, I added that VI Analyzer test, and AEH is one of the many topics I discuss in my What to Expect When You're Expecting an Error presentation: http://bit.ly/dnatterrors

If you don't agree, that's fine... just deselect the Auto Error Handling Enabled VI Analyzer test in your configuration.

---

I fall into the same camp as you Darren. The application should always include proper error handling. By doing so you put more thought into the design and code and in my opinion end up with a better more robust application as a result of it.

[RTSLVU]

I also have to agree that error handling is program and error specific there is no one way to handle errors.

In general on an error you should:

1. Put the UUT into a safe state (Shut down power sources etc.)
2. Log the error and some debug info
3. Halt the program
4. Display an error message

But in the case of communication errors:

1. Ignore / clear the error
2. Retry communications a few times
3. If that fails
4. Put the UUT into a safe state
5. Log the error and some debug info
6. Halt the program
7. Display an error message