Message Edited by Darren on 10-16-2006 11:38 AM
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
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.
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.
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).
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:
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.
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! 😉
Message Edited by Darren on 10-16-2006 02:57 PM
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.
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... 😉
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.
There are also times when I want to save cleanliness on my diagram because I know certain nodes won't ever generate errors.