Interesting comments. I think we're about to "branch" into a discussion of coding styles vs. using the debugger, per se.

Call it massive hubris, call it what you will, but I simply don't run into many bugs caused by me.

I started programming in an industrial environment where line time was $7,000 per hour. If what I did caused problems, I heard about it real fast. Subsequently, by habit I learned to "battle-harden" my code.

Basically, my routines assume that nothing will work. I estimate I spend over 90% of my coding time stamping out possible error-causing conditions, usually before even starting on the code that actually does useful work!

Again, maybe it's hubris, but I find that with my own code (and even with a lot of other people's) I can simply read it, and understand what it's doing.

>The debugger has been invaluable to me in 3.0, 5.0, and 6.0. Each version has gotten better. It doesn't mean I can't crash it. Try putting in a watchpoint on Excel object. Yikes! :)
>
>Seriously, yes there have been bugs, but I do not understand how people can debug their code...actually just understand their code w/o using the debugger. I don't mean that badly, I honestly just don't understand.
>
>For example, if I'm coding something with any branching, I step through new code just to see how it behaves. I find bugs I'm not even looking for. It's especially helpful if I'm having to untangle somebody else's code. In 6.0 I have the coverage profiler, so it'll be much more efficient to make sure all branches are tested.
>
>
>>I'm still working in VFP5. The vast majority of the kinds of bugs I get, the debugger basically blows up spectacularly and I have to kill the debugger/VFP through the NT task manager. An excellent example was my recent thread "SQL: Statement Too Long for no apparent reason". SET STEP ON just before what turned out to be the offending code (MSKB problem, in fact) didn't help at all.
>>
>>Is the VFP6 debugger substantially improved over that in VFP5?