Several Means to Debug

There are times when you will face trouble while coding that you can not just solve it through analytical means or using indirect means like unit test. This is the time when you need to get dirty, no other options left except to debug it.

After you past any emotional trouble because of it, this is a time you see what options still available to you. Here they are from the simple one to the one that require more resource to do :

• Print it. If you can code in any language, chances are you can print "Hello World" with it and that is what you can do to track how your code behave in the area you predict to be a problem. One strategy that can be use to pinpoint the problem is to put print before what you think the trouble occur and after it and if it doesn't print the second one, the hypothesis is correct that it is happen in that area. The next step is to shorten the range between the first and second print until you get close enough to the exact line.
• Pop up. Same as the above, except in the context of programming involving GUI. If you work with GUI you most probably know how to popup a Messagebox. Just pop it up in places you want to see some value. The first and second print strategy above would work too.
• OS Debug API. There are times when you can not see characters that you print in an obvious way i.e: your code run inside other process that hide it. This is where it gets a little tougher (only a little though). You could use a Debug API provided by OS, call it in your code and view it with tools that can view it. In Windows you could use OutputDebugStr API or other variant or wrapper of it and view it in DebugView.
  
• Debugger. This is the most complicated one but the most versatile one. Master this and you'll make your coding-life easier. Debugger is an external tool (although in IDE like visual studio it looks integrated) so you need to learn it first instead of just rely on your knowledge of the programming language. Debugger could trace your code while running, step on it line by line and you could see lots of useful values to trace the problem on your code. Most importantly you could analyze program that crash when in runtime with it too.
  

Not all hope is lost when your code does not work and you have lost any analytical means to try to fix it. It's time to put your empirical hat and start tracing away.