>>>>
>>>>Errors silenced by TRY ... ENDTRY are hardest to find IMHO. Instead of silencing handle them ( sometimes they may be silenced on purpose ).
>>>
>>>Ok. In my view TRY ENDTRY does not silence the error (without CATCH) since ON ERROR is fired. IMHO if the TRY-ENDTRY were completely isolate the problem (silence it), the ON ERROR would not fire.
>>>But as long as I understand how it works, it is fine.
>>>
>>>Update. I want to be sure you don't think I am arguing with you - you know VFP much better than me. I agree with what you said that TRY ENDTRY silences the error (undeclared variable). But another error handler is catching it and to me it means that the error was not ignored completely. That is, it was not silenced. In fact, I admit, I used to think that TRY - ENDTRY will completely isolate the error. That is, if I write any kind of JUNK code within TRY ENDTRY, the user will never see it. And I was wrong. This is all I wanted to confirm.
>>
>>But why would you ever have TRY without CATCH?
>>
>>Tamar
>
>I have many places in my app where I want to log a certain event (for testing or an audit). This is done by calling Strtofile() function to update a .log file. I didn't care if it was successful, for whatever reason (e.g. if the drive was not accessible) and didn't want to alert the user of the problem. So, by mistakenly thinking that TRY-ENDTRY will silence the error, if it happens, I used the TRY - ENDTRY around all of these places where I was writing the log. What happened a few days ago is that there was an error in the STRTOFILE() where I was trying to log a value of a global object. And the global object was not yet instantiated. And I saw the error in the global error handler. Made me think and I discovered how it really works. So, now, whenever I do the TRY ENDTRY (for these "insignificant" case), I will add CATCH without anything. And this will truly silence the problem. And I thought that at this point of my career I knew absolutely everything about VFP - Joking :)

You write "around all of these places where I was writing the log", Why don't you simply create ONE method which does the logging for you? Then you can call this method whenever you want to add something to the log.