LabVIEW
Scary LabVIEW images
Solved!
@CMal wrote:
On the subject of scary images, LabVIEW was recently honored by an article on thedailywtf.
See also Yair's post from ~10 days ago.
@Mark Yedinak wrote:
@CMal wrote:
On the subject of scary images, LabVIEW was recently honored by an article on thedailywtf.
Chris M
Unfortunately people are taking an example of extremely bad code and using that to bash LabVIEW. When I have some time I will need to reply to some of the ridiculous posts over there.
Thanks for the heads up.
@SynergyMike wrote:
Ok, now you have my curiousity piqued... in LV7 code that I took over, I found numerous instances where, in order to test for the existance of a directory or file, the error cluster was used. In order to preserve dataflow, I added a clear error to each instance of a case structure that had selected the error - is there a preferred alternative? (The VI probably has 5 or 6 clear errors total).
Michael Tracy
Synergy Microwave
Legacy code get grandfathered 
out of modern expectations but there are functions on the Files Advanced palette to list check etc.
To judge my own rules I tend look at a software developers relationship to their code as analogous to a doctors relationship to their patient. To evaluate the current state, the doctor will probe and look 
for specific conditions and/or reactions. A patient recoiling when the abodmen is probed could indicate a specific ailment while attempting to open the file the user specify returning an error 7 File not found, or parsing a binary file and check from error 4 EOF are specific checks for conditions that we expect will happen. The attempt to do the operation followed by the observation are a valid methodology. Of course pulling out that ultrasound scanner instead of poking is a better approach as is using the functions on the advanced palette that check it the file exist.
I prefer the more elegant approach when I am aware it exist and it is available. 
Extending the anaology...
But using the "Clear Error" is not a specific probe. It would be like a doctor treating an in-grown toenail by cutting the nerve and telling the patient to go about their life as normal. The code construct of "Clear Error" followed using the data downstream just feels like cut the nreve and go on situation. 
Full Disclosure time!
In my Control Ref Nugget I used a similar construct but rather than using the Clear Error function, I used a Case Structure selector to handle the error returned when the class was wrong. For the sake of that Nugget, it was acceptable since it would have introduced more complexity to an already complex subject. But I digress.
So Using Clear Error is not malpractice. Over use on the other hand if not abusive should give any careful developer reason to investigate (In my case shiver and fear for the sake of my patient not knowing what kind of gangreenous growths I will find inside the extremities). 
But that is just my 2 cents and I admit that I have an analretentive side and the control freak in me wants it to be "error free" and as Christian mentioned above, "Is it really 'Error Free' ?".
Re: 31 instances! 
That is beyond scarry. Are you being punished for something?
Ben
@tst wrote:
Sorry. 11, 31 or 291 uses of the clear errors VI are not a problem in themselves. You need to see how they're used in the context of the code to see if that usage was reasonable
Ageed. After you examine the context.
This thread is all about scary images. When you do a search and find 291 Clear errors and you DON'T know what is the context, its scary.
Is there a story that goes with the number 291?
Ben
