David Hopwood wrote: > > Joe Marshall wrote: > >> > >>I do this quite often. Sometimes I'll develop `in the debugger'. I'll > >>change some piece of code and run the program until it traps. Then, > >>without exiting the debugger, I'll fix the immediate problem and > >>restart the program at the point it trapped. This technique takes a > >>bit of practice, but if you are working on something that's complex and > >>has a lot of state, it saves a lot of time because you don't have to > >>reconstruct the state every time you make a change. > > The problem with this is that from that point on, what you're running > is neither the old nor the new program, since its state may have been > influenced by the bug before you corrected it.
Yes. The hope is that it is closer to the new program than to the old. > I find it far simpler to just restart the program after correcting > anything. If this is too difficult, I change the design to make it > less difficult. In the most recent case where I was doing this, I was debugging transaction rollback that involved multiple database extents. It was somewhat painful to set up a clean database to the point where I wanted to try the rollback, and I wanted a pristine database for each trial so I could examine the raw bits left by a rollback. It was pretty easy to deal with simple errors in the debugger, so I chose to do that instead. > > > Wow, interesting. > > > > (I say the following only to point out differing strategies of > > development, not to say one or the other is right or bad or > > whatever.) > > > > I occasionally find myself doing the above, and when I do, > > I take it as a sign that I've screwed up. I find that process > > excruciating, and I do everything I can to avoid it. Over the > > years, I've gotten more and more adept at trying to turn > > as many bugs as possible into type errors, so I don't have > > to run the debugger. > > > > Now, there might be an argument to be made that if I had > > been using a dynamic language, the process wouldn't be > > so bad, and I woudn't dislike it so much. But mabe: > > > > As a strawman: suppose there are two broad categories > > of mental strategies for thinking about bugs, and people > > fall naturally into one way or the other, the way there > > are morning people and night people. One group is > > drawn to the static analysis, one group hates it. > > One group hates working in the debugger, one group > > is able to use that tool very effectively and elegantly. > > > > Anyway, it's a thought. > > I don't buy this -- or at least, I am not in either group. > > A good debugger is invaluable regardless of your attitude to type > systems. Recently I was debugging two programs written to do similar > things in the same statically typed language (C), but where a debugger > could not be used for one of the programs. It took maybe 5 times > longer to find and fix each bug without the debugger, and I found it > a much more frustrating experience. > > -- > David Hopwood <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list
