Darren's Weekly Nugget 10/16/2006

[Darren]

There is a feature that was introduced in LabVIEW 7.0 called Automatic Error Handling, which is a property of VIs that allows you to see error dialogs pop up if nodes on the diagram return errors and you don't have those error outputs wired.  If you rely solely on this feature to be informed of errors occurring on your diagram, you need to change your ways!  I suppose the main purpose of this feature was to help new LabVIEW users who were still grasping the ins and outs of dataflow, so they wouldn't have to worry about error handling on top of everything else.  Well, if you're reading this nugget, then you're experienced enough to start using an effective error handling scheme in your VIs such that you shouldn't need to rely on Automatic Error Handling anymore.  Check out this screenshot:

By default, LabVIEW enables the Tools > Options > Block Diagram > Enable automatic error handling in new VIs option.  You need to turn off this option in lieu of actually wiring up all your error IO terminals in your VIs.  I do recommend, however, that you leave the Enable automatic error handling dialogs option checked, as it's good to know if any VIs you're using (or have written in the past) still have this option set on them...not to mention VIs you've obtained from someone else who hasn't yet turned off this option.

Remember, Automatic Error Handling will pop up an error dialog when your VI is running if any node on the diagram with its error output terminal unwired returns an error.  This could be very bad if you have a critical application running that all of a sudden freezes because an error dialog has popped up.  This is one of the main reasons why I recommend using error wires to handle errors instead.

-D

P.S. - Check out past nuggets here.

Message Edited by Darren on 10-16-2006 11:38 AM

[tst]

Agreed. As I keep saying, I think that the automatic handling should be left on to catch those times when you forgot to handle something or even to inform you of errors if you're writing quick and dirty code just to check something.

I have seen people argue that leaving it on will cause programmers to be more negligent because they have a safety net, but I think that that is just a psychological matter and should be resolved by the programmer (you don't see people driving carelessly just because they're wearing seatbelts, right?).

If I remember correctly, a built application will not popup an error message in any case, so if you're writing a critical application, I don't think there should be a problem. In any case, you can write a tool to go over all the VIs in your hierarchy (to a degree) and remove the option before building the application. Of course, using such a tool would not be very convenient for several reasons.

Correction - apparently, we're not in agreement. Do you think that it's better to have a new VI without the AEH (because you forgot) than to have it with it? If your new VIs don't have AEH turned on, then the global setting will have no effect on them. If it is turned on, then you can use the global setting to disable it in all VIs at once. You could probably also add a setting into the INI file of your application to disable this, if needed.

Message Edited by tst on 10-16-2006 07:29 PM

[smercurio_fc]

Turning off the automatic error handling is one of the first things I do when I install/reinstall LabVIEW. I was annoyed that NI made the default "on" back when it was first introduced, but I can't really fault them for having done so, based on your point, Darren.

To tst: "you don't see people driving carelessly just because they're wearing seatbelts, right?" No, I see them driving badly because they're talking on the phone, or hunting for their phone, or dialing their phone, or putting on makeup, or reading the newspaper (seen this one several times), or shaving (at least it was an electric), or ...

[tbob]

How about talking on the phone and putting on make-up at the same time while driving.  I've seen that one.

To get back to the original subject, I use automatic error handling during development.  After fully tested and before releasing to production, I turn it off.  I can't have error popups occuring during the middle of production since many times the stations are unmanned and operate automatically.  Of course this is my particular scenario and choosing the auto handling will be different for different occasions.

[Darren]

Regarding tst's reply, I'm saying that I would prefer that new VIs not have the option set, because I really don't want any auto error handling dialogs ever coming up.  Assuming my colleagues feel the same way, I prefer having the dialogs enabled, in the event that I (or one of my colleagues) have inadvertently saved a VI with the option set.  Ultimately, it's my opinion that all error handling should take place on the diagram via error cluster wires...if there is an unwired error cluster that may cause an automatic error handling dialog to come up, I'd like to know about it so I can fix the VI (or notify its owner) appropriately.

-D

[tst]

---

Darren wrote:

Regarding tst's reply, I'm saying that I would prefer that new VIs not have the option set, because I really don't want any auto error handling dialogs ever coming up. 

...if there is an unwired error cluster that may cause an automatic error handling dialog to come up, I'd like to know about it so I can fix the VI (or notify its owner) appropriately.

---

The way I understand it, these 2 contradict each other. I can understand not wanting an automatic dialog in principle and there is a simple way to do this - wire all error outputs!

If you want to be notified, however, you WILL need the dialog during development (like tbob said).

Unless...

Maybe the VI analyzer should analyze unwired error out terminals as well?

As for how to get rid of the dialogs, quoting from the help:

---

Enable automatic error handling dialogs— ...Remove the checkmark from this checkbox if you do not want LabVIEW to suspend execution and display an error dialog box when an error occurs, even when the VI has automatic error handling enabled...

---

This means that LV will only popup a dialog if the VI has the option checked AND if the global option is checked. When you don't want popups, uncheck this. When you do want them, check it.

What I'm saying is not that you shouldn't wire the error cluster. You definitely should. I'm just saying that there are cases when you don't and if you don't have the option enabled in new VIs then you won't know about it.

[Darren]

I recognize that the two seem to contradict each other.  But here's the thing...none of the VIs I create from scratch should have auto error handling enabled...that's good, because those VIs will never pop up a dialog.  However, there's a chance that a VI I inherit from an old project, or perhaps a VI that one of my colleagues gives to me, *does* have auto error handling enabled.  In those cases, I *do* want to see an error dialog, because that will tell me that not only does this VI need its auto error handling dialog turned off, but it also needs some work so that it handles errors better.

Oh, and your suggestion about the VI Analyzer is a great idea!  Oh, wait a minute...we already have that test:

Note that the test allows you to "ignore" several different nodes for which we commonly ignore the error output.  Enjoy!  😉

-D

Message Edited by Darren on 10-16-2006 02:57 PM

[tst]

So what you're saying is that there are cases where there could be a potential error but you would rather not know about it?

A case in point - you create a Visible property node for a control. Can it have an error? Not as far as I know.
Do you wire the error out terminal?

Now, disconnect the node from that control and you suddenly have an option for an error (invalid reference, error 1055 or 1073, I don't remember which). Suppose that, for whatever reason, you did not wire the error out terminal, what do you do when there is an error? You don't know about it.

Now, let's suppose the other option - you DID wire the error out terminal. In that case, the AEH will not kick in and you should see no difference from the current way you work.

Basically, if you do wire all the error out terminals which can produce errors (which is what you should do), then you shouldn't mind having the AEH, because it will simply not do anything. THAT's my point.

[Darren]

I understand your point, but I don't necessarily agree with it.  There are times when I don't wire the error output of nodes, and I'm ok with them generating errors and me not knowing about it.  There are also times when I want to save cleanliness on my diagram because I know certain nodes won't ever generate errors.  That's why there are the "exceptions" in the afore-mentioned VI Analyzer test.  As an example of the first scenario, let's say I'm dealing with a ton of VI Server object references in my code...I may be indexing out of the array and doing stuff with certain references...perhaps I'm even closing some of them in subVIs.  But to make my code more readable, I may simply wire the entire array of references to a For Loop at the end of my code that closes all the references.  Some of them may already have been closed, but I don't really care, thus I really don't care if the Close Reference in the For Loop returns a 1055 error for some of those.  For the second scenario, there are times when I'm dealing with variant datatypes and I am 100% sure what the correct type of the variant is...for that reason, I don't wire the error IO on the Variant To Data function, since I have total control over the data structures in my code.  In fact, I would say that 99% of the time in my code, I don't wire the error IO on Variant to Data.

And yes, that implicit "Visible" property could potentially return an error..."Error 2:  Memory is Full" is one I can think of.  But then again, you probably have bigger worries than that particular node if you get that error... 😉

-D

[tst]

---

@Darren wrote:

There are also times when I want to save cleanliness on my diagram because I know certain nodes won't ever generate errors.

---

There's a point I can relate to - avoiding passing an error cluster to keep the diagram clean when you can ignore errors. In that case, I could see how not having AEH would be useful. My own personal method for getting around this is simply wiring the error out cluster into the nearest structure border. That would prevent the dialog and (assuming there's a nearby structure) keeps the diagram clean. Another option is the Clear Errors VI (which can have its icon changed to be much smaller.