Comment you're replying to
Your name *
Your email *
Your comment *
Please type these numbers *
There was an error submitting your comment, sorry..
The number one problem I find when I help someone debug a problem is the assumptions that have been made.
If you’re running a program and it doesn’t behave the way you expect it to what are you going to do? “Step through the code to see what’s going wrong” you say? Chances are that will only help you if you’ve done something obvious, like a typo or a missing bracket. Besides which there are lots of times when stepping through code is impractical or just not possible, such as when the problem is in a CSS style expression. Debugging these is a downright pain.
The first thing you should do after the obvious leads are exhausted is to CHALLENGE YOUR ASSUMPTIONS! (Yes I’m shouting it.)
I can’t stress this enough – back to the aforementioned CSS style, what kind of assumptions have we made:
Simple questions to answer but do ask them. A lot of the time you’ll notice that you aren’t where you think you are – which explains why you’re going the wrong way.
If you don’t use this gem of a method you’re only slowing yourself down. This comes right back to challenging your assumptions. The Assert() method allows you to add a test expression and a message into your code – when the test fails the message is displayed. The beautiful thing is you can leave them all over the place, because when you compile for Release the compiler leaves them all out.
You should include one of these whenever you make an assumption in code – because we can’t always remember our own rules, and sometimes we’re not the only ones using our code. For example, I recently had a problem with a form’s progress meter not displaying properly – I never got any value from it. I added a Debug.Asset() to check the value of pb.Maximum – surely the maximum value was not set to 0 – it should be the record count from a record set I had just loaded. Oh no… turns out the call to set the maximum and the call to load the records were in the wrong order. The Assert pulled me right up. This gets even better when you’re programming in a multi-threaded environment, because the act of debugging interferes with the way the threads behave, since you artificially slow down the execution.
Two more little gems, these. Quite often people ask on news groups and the like “how do I debug a Windows Process”? EASY!
In your Start() method simply add:
When the run-time hits the first line it will pause processing and prompt you to attach a debugger. The second line is a programmatic break point (which you don’t officially need but the Launch() breaks you into the Dissassembler instead of the code).
If you’re a web programmer you may already know about…
and you’re done.