Automatic error handling

[billko]

---

@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.

---

Hi, Darren:

It really is as simple as how I described it.  So I am guessing it's some kind of peculiarity with this particular setup.  I know there are a few combinations of things that can occur to yield the :No debug info" grayed out probe, like i think placing a probe in a standard FOR loop, and I just assumed this was one of them.  So there must be something interesting going on.  Oh, I forgot to mention that these VIs run in a TestStand environment.

Except for this "alleged" issue with probes, I usually create executables (where AEH is turned off by default anyway) so I never rely on the popup anyway.  I agree it's a lazy tool that inexperienced programmers can easily abuse to the point where they don't understand what error handling actually is.  I just thought it needed to be enabled for probes to work, but this isn't the case.

[rwunderl]

I agree that AEH is a crutch for beginners, but I also agree with @1984 that it has some use as a way to catch a programmer's mistake of not wiring an error out. (But only if an error occurs while you're watching!) To the OP's point, if you wired all of your errors, you wouldn't have a problem in the first place.

I keep AEH turned on by default, but I turn it (and debugging) off for any VI that is trivial. Again, this catches my mistake by default if I forget. Otherwise, the VIs are happy and efficient.

Also, if you do keep AEH turned on during development, only do so while testing in the development environment. You should probably turn it (and debugging, if applicable) off en masse before you compile your executable. If for no other reason than the performance benefits. I created a simple tool long ago that would manage this across my entire project in case I forgot one or two.

[tst]

---

@rwunderl wrote:

You should probably turn it (and debugging, if applicable) off en masse before you compile your executable.

---

That should not be necessary. AEH doesn't apply in a built EXE, which is exactly why I do leave it on.

My position is:

1. Handle errors in your code. Do it properly and don't rely on AEH.
2. Leave AEH on just in case you did miss something somewhere. If you really do want to ignore errors somewhere, you can wire the error wire out into something.
3. Build an EXE for the actual system and then AEH doesn't apply.

[paul_cardinale]

One of my cow-orkers uses this approach: 'Don't worry about errors'.  When something goes wrong, his code just silently does the wrong thing (and hey, it's less wiring on the block diagram!)..

[rwunderl]

---

@tst wrote:

---

@rwunderl wrote:

You should probably turn it (and debugging, if applicable) off en masse before you compile your executable.

---

That should not be necessary. AEH doesn't apply in a built EXE, which is exactly why I do leave it on.

---

That may be true in general, but EXE's with debugging enabled that call PPL's with debugging enabled do pause strangely on unhandled errors where an AEH dialog would otherwise have popped up in the development environment.

Curious as it may be, I've never spent the time to give it much thought. I just disable AEH. However, I do want to maintain the ability to probe the compiled code for advanced debugging when necessary, so I leave debugging enabled in that app. (This is just one example, not really the norm.)