>>>>In VFP 8 TRY/CATCH - robustness on steriods?:)
>>>>>
>>>
>>>Hmmm, you could say that, but I view TRY/CATCH differently from ON ERROR. I'd use the former for exceptions as opposed to general error handling. For example, if you attempt to open a file exclusively but can't because some one else has it in use, that's an exeception, not an error.
>>>
>>>Why? Simply because the operating system is telling you this. There's nothing wrong with the code or the value passed to it. In contrast, if I attempt to open a file that doesn't exist, that's a coding error, since you should check to make sure that the file exists before you attempt to open it.
>>
>>It seems that a process that attempts to open a file in exclusive use by another is also a coding (logic?) error. I must admit, however, that I have never been proven right, only wrong:)
>
>I think that if you take the time to consider it, you'll find uses for both exception handling (TRY/CATCH) and, of course, error handling (ON ERROR).

I use ON ERROR to isolate my coding errors. Try/Catch (though EPS gave our UG a great presenattion) is for projects more sophisticated than mine. I have to admit, I wrote programs for years without an ON ERROR (thought it was for sissies:), but now my first block of code (err paste in) is ON ERROR. Time has forced me to be less precise than I was in my youth!