程式的bugs越少，最终用户对这个程式的评价越高。而研发人员事先对bugs的处理越多，最终用户能提供的关于bugs的信息就越多，也越准确，这样，研发人员在接到最终用户反映之后，就能够快速找到出现bugs的那部分代码，并以最快速度发布程式的升级包。
在这份教程中，我们从最基本的部分开始，逐步介绍许多在调试程式时“应该做”或“不应该做”的原则。正如您将看到的，这份教程中所指的“调试”这个词所包含的意思很多，而不只是如大部分人所想到的--利用IDE集成的调试器的“调试”。我希望读过这份教程之后，读者能够在思路上有所收获。
写易读的代码
第一点，大概也是最重要的一点，就是写干净易读的代码。易读的代码是很有价值的。请想象一下，假如随便扫视一眼代码或注释，就能立即知道这段代码的的作用，连同在写代码的时候为什么要这样写，当时的思路是什么，那么就能够节约大量时间。这样的代码，在写的时候可能会稍稍慢一些，但是，当您调试程式时，就不会花上几个小时来寻找bugs，相反，您能够快速，简单的完成除错工作。这时，您就会觉得多花一些时间使程式易读是很值得的。
所以，我推荐您在写程式的时候，应该养成自己的风格，或是读一读Scott的关于代码风格的文章。
使用Exceptions和Exception的处理方法
我们教程的下一步，仍然是以代码为基础的。因为除去一些少数的情况，研发人员不可能总是依靠于集成的调试工具。所以，学会用其他的方法来找到烦人的bugs是很重要的。一些重要的、处理的错误可能会在窗体之外发生。在C 标准定制出来之前的黑暗日子里，在程式里面发出发生错误的信号，通常是通过返回错误代码完成的（现在这种方法仍然应用于OLE技术和一些Winapi函数），这样的处理方法很容易就会被忽略。（比如说，您经常检查winapi函数的返回值吗？）所以，出现问题的可能性并不小。由于以上的原因，我们需要一个这样的机制，他能让我们不能忽略这些错误，而且，这个机制应该能被我们控制和自定义的。在这样的需求下，异常处理机制出现了。需要一个特别的错误类型吗？简单，定义一个新的异常类型就行了（和定义一个类的方法差不多），然后抛出（throw）他。下面这个例子说明了这一过程。
例1：
//----------------------------------------------------------------
class MyException
{
public:
