Jay,

I disagree with everyone saying TRY/CATCH is for errors only. Be creative. TRY/CATCH is a good thing.

You can THROW a user thrown error (2071) and catch it. Sure, I suppose that a user thrown error is technically an error, too.

And I use the same concept of setting m.Successful to .t. right before the CATCH line meaning if the code got all the way throw without any user thrown errors or hard errors then all is good. And I'll set m.Successful to .f. in the CATCH or initialize it to .f. in the beginnning.


>You know, I started writing it using m.Successful and then setting that to .F. if something bad happend. After the code was done I would check the value and do something based on that, but I thought it was too old-style and wanted to find something more contemporary. Guess I'll just end up doing it the way I've done it for 15 years. I just assumed there must be a better way now.
>
>
>>If you're using an object property instead of the variable, you can give it an assign method.
>>
>>It would not help you to go out of the code block, though :( But at least gives you a way to process it.
>>
>>
>>
>>>Ok. Just for errors. So, how would I trap when a variable value changes then? There are a number of things happening in that block of code and I want to be able to say, "Hey, look! The value change, so let's jump down to this other standard block of code and handle it." If I use IF or CASE, I could end up with 20 different conditional blocks. Seems like there should be a way to just get out and handle it without all the extra code.
>>>