Hi, Frank!

Hope you're doing well.

>>ASSERT. Use ASSERT, not SUSPEND or SET STEP ON.
>>
>>1. It works.
>
>As long as SET ASSERTS is set to ON.

Exactly. That's a Good Thing (tm). :)

>>4. IT WON'T CAUSE PRODUCTION CODE TO CRASH IF YOU ACCIDENTLY LEAVE IT IN.
>
>Well, you are right about SUSPEND, but SET STEP ON is ignored in an .EXE since VFP7.
>(Also SUSPEND just suspends while SET STEP ON also opens the debugger, so you have an visual clue that the program is in suspend mode, and is not 'stuck')

Fair enough. Thanks for correcting me.

>>SET SOAPBOX OFF
>
>First I never use SUSPEND, especially for your 4th reason.
>My preference is to use ASSERT for all critical messages that I want to trap in the future or by other developers.
>I use SET STEP ON when a breakpoint does not work, although I use a changing breakpoint on "something"$PROGRAM() more and more which hasn't failed on me (yet). I also use it when the UI is too slow if the debugger is opened. I always (try to <s>) make sure I don't leave SET STEP ON in my code that I put under Sourcecontrol.

It's that last "try" that makes me strongly push ASSERT. For what it's worth I occassionally use SET STEP ON but only under exceptional and infrequent circumstances.

I forgot the most important reason! You control whether you do, indeed, need to stop. If a condition is alright, you don't get the message. That helps with debugging a routine that *sometimes* hits the error condition.

>IOW: I use ASSERT to have permanent faillure checks while I use SET STEP ON as a temporary meausure when a breakpoint doesn't work. Which also means that a SET STEP ON 'forces' my pinky to go towards the DELETE key, while an ASSERT doesn't do that for my pinky <s>.

I too use permanent ASSERT in error handling, and I'll yield (a little) on SET STEP ON. But only cuz it's you. ;-)