LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how can I check if a directory already exist

Mike, I wholeheartedly agree that error handling is important. The point I was making is that turning off auto-handling can be very dangerous if you don't handle the errors (for whatever reason - forgetting, not being a good programmer, being distracted by a good pizza...) and is meaningless if you do handle the errors. Bottom line, my opinion - leave auto-error-handing on.

___________________
Try to take over the world!
0 Kudos
Message 11 of 14
(743 Views)

I will jump in with my $0.20 worth (hey everything is more expensive, what's $0.02 going to get you!?). I know where Mike is coming from, having worked with him and seen and adopted some of his very cool error handling techniques (check out his error merger from a relatively recent post, you won't use the "standard one"). The problem I have with the automatic error handling default is that if the person using it knows that it is there it does foster not thinking about error handling. As to NI putting these features in, much of their own functions effectively use auto error handling in that they pop up a dialog and don't pass the error cluster out. Most of these are legacy functions from the earliest days (file i/o in particular), but it doesn't help to try and get developers in the habit of thinking about and using error handling. I promote it for the obvious reason of aiding integration/debug/troubleshooting but also because thinking about possible errors in your code and how to handle them almost inevitably results in a deeper analysis of the logic behind each section, which usually results in better code. Initially more work, ultimately less. Given all that I agree that some error checking, whether handled optimally or not, is better than none. I do, in my line of work, look at a lot of other folks' code, much of which can't easily (or at all) have error checking/chaining added and to try and to figure out what isn't working the new feature has been a big help. 

So there a firm stand in the middle of the discussion!Smiley Very Happy

P.M.

(mp both "lp" and "bp" are doing well, in fact "lp" will see "bp" in Austin the week of the 15th. is there a chance lp will see mp? or should that be pm see mp?)

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



Message 12 of 14
(737 Views)
Unfortunately, mp and pm will not be able to get together in tx because we will be in va dropping mp-jr off at vmi. Smiley Very Happy
 
Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 13 of 14
(729 Views)
I have inherited some code written by someone else where the error ins and outs were not wired in all cases, and automatic error handling was turned off.  The program was full of errors that went by unnoticed until I turned auto handling on.  No excuse for bad programming.  I fixed all the errors.  But now I keep auto handling always on and strive to write code that will never have to use the auto handling feature.  If I see an auto generated error message, I look into the code and fix it.  No one is perfect and we all miss things now and then.  Automatic error handling should be kept on to catch those little gotcha's.  Programmers should strive to fix any problems that will invoke an auto generated error message.  The best of both worlds.  In other words, automatic error handling should be used to catch errors that programmers missed, but it should not be relied upon to handle the errors.  Always keep it on, but fix the code when an auto error is generated.
- tbob

Inventor of the WORM Global
0 Kudos
Message 14 of 14
(712 Views)