07-28-2005 07:41 AM
07-28-2005 08:04 AM
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!
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?)
07-28-2005 09:16 AM
07-28-2005 12:15 PM