Darren's Weekly Nugget 10/16/2006

[Ben]

After reading you two go back and forth, let me chime in.

I do not think I have a hard and fast rule re the AEH (aside from shutting it down and handling error cluster explicitly).

Many of applications are actively controlling something to ensure my widget is not not destroyed durring testing.

These application typically have documentation that explains all possible screens and how to react.

I do not want an operator to be presented with a screen they have never seen before that allows them to stop all of my control loops.

Our need to monitor the errors from the bowls of an application did not develop with the introduction of the AEH. Prior to that introduction, we developed an Error Handling Suite" that gets bundled into most of our applications. One of the handiest components in our suite is a VI that will posts all error clusters where the error boolean is set to a single queue that is monitored by a background process. This gives us the best of both worlds. We can go back and analyze the errors taht were logged the last time the program was run and trace through the events that lead to a crash (for example). I simply teach my rookies to handle all errors that will affect the operation of your code, and every other error cluster gets wired to the "Post Event".

Ben

[MRedRaider]

I ALWAYS WIRE ERROR... ALWAYS. If I find myself disgusted by the appearance of a VI because of the error... then that is when I break the functionality into subVIs.

As for not wanting pop-ups vs. no notification of errors... May I suggest an XControl error cluster that automatically logs errors... heck, mine even emails me the error on networked machines. For "production down" errors (Hardware timeouts... etc), I get a notification on my phone and I am out at the station before they can call me.

***My opinion:  Any error is worth recording. How else can we learn about flaws in our code. Yes, even errors that I expect get logged locally on the Test PC.

Okay... now... go ahead and shoot me in the foot for overkill. Note that I am the only LabVIEW developer here and I go to great lengths to prevent the old "The test system was down" excuses at the end of the month.

[tst]

---

@Ben wrote:

I do not think I have a hard and fast rule re the AEH (aside from shutting it down and handling error cluster explicitly).

---

I will try to say it again, more clearly now - once you're handling all errors explicitly, it makes absolutely no difference whether AEH is off or on. The dialog will simply never pop up.

---

I do not want an operator to be presented with a screen they have never seen before that allows them to stop all of my control loops.

---

Agreed. Completed applications should not have unwanted dialogs. As I said, as far as I can remember, the RTE never pops up errors, regardless of the settings in your IDE. If the operator station uses LV, then you can simply disable the global setting. The point is that this option is only used to help the developer catch missed wirings during development, nothing more.

[tst]

I did finally find a place where having the AEH on is problematic.

I got some VIs from someone else where the AEH was turned off and where an Open Application Reference node was throwing an error. The error wasn't caught and I didn't notice it because it did return an application reference. It was just that the app reference was unusable and generated errors down the line. It took me several minutes to notice that the error out terminal was not wired out, because the app ref was OK and I expected an error dialog to be displayed if there would be a problem. Had I not expected an error to be displayed, I might have found it sooner.