Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!unisoft!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Mini-flame: Debugging Techniques Message-ID: <11051@hoptoad.uucp> Date: 8 Apr 90 18:45:43 GMT Organization: Eclectic Software, San Francisco Lines: 30 There are an awful lot of programming problems posted to this place which seem to show a defective understanding of debugging. People seem to think that they will be able to solve all their problems through deduction, by sitting back and thinking about what might be causing the problem and what might be a way to solve it. This is a good way to solve many problems, but for many others (perhaps most), you need to use an empirical method, to wit: breaking into the debugger, stepping through your code, and seeing where it breaks. (The alternative is to insert probe statements which put out information that allows non-debugger tracing of execution, but this doesn't apply to many problems in obscure environments or inside system code.) Long-timers will notice that I'm giving many fewer answers here than I have in the past. One of the major reasons is that I've reached my limit on people who go to the net for an answer before they'll apply the very simplest local debugger strategies to their problems. You will *have* to do this to become a professional programmer, and it will have to become routine for you. There are too many problems that are tractable only to debugger methods. The net does not exist as a substitute for your use of basic programming techniques. It is rude to post a question to the net which you could answer yourself with a small amount of work sitting in front of your computer. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "As I was walking among the fires of Hell, delighted with the enjoyments of Genius; which to Angels look like torment and insanity. I collected some of their Proverbs..." - Blake, "The Marriage of Heaven and Hell"