[转载]掌握C++Builder的调试艺术

（作者：霍炬编译）

　　程序的bugs越少，最终用户对这个程序的评价越高。而开发人员事先对bugs的处理越多，最终用户能提供的关于bugs的信息就越多，也越准确，这样，开发人员在接到最终用户反映之后，就能够快速找到出现bugs的那部分代码，并以最快速度发布程序的升级包。

　　在这份教程中，我们从最基本的部分开始，逐步介绍许多在调试程序时“应该做”或“不应该做”的原则。正如你将看到的，这份教程中所指的“调试”这个词所包含的意思很多，而不只是如大部分人所想到的--利用IDE集成的调试器的“调试”。我希望读过这份教程之后，读者可以在思路上有所收获。

写易读的代码
　　第一点，大概也是最重要的一点，就是写干净易读的代码。易读的代码是很有价值的。请想象一下，如果随便扫视一眼代码或注释，就能立刻知道这段代码的的作用，以及在写代码的时候为什么要这样写，当时的思路是什么，那么就可以节约大量时间。这样的代码，在写的时候可能会稍稍慢一些，不过，当你调试程序时，就不会花上几个小时来寻找bugs，相反，你可以快速，简单的完成除错工作。这时，你就会觉得多花一些时间使程序易读是很值得的。

　　所以，我推荐你在写程序的时候，应该养成自己的风格，或是读一读Scott的关于代码风格的文章。

使用Exceptions和Exception的处理方法
　　我们教程的下一步，仍然是以代码为基础的。因为除去一些少数的情况，开发人员不可能总是依靠于集成的调试工具。所以，学会用其它的方法来找到烦人的bugs是很重要的。一些重要的、处理的错误可能会在窗体之外发生。在C++标准制定出来之前的黑暗日子里，在程序里面发出发生错误的信号，通常是通过返回错误代码完成的（现在这种方法仍然应用于OLE技术和一些Winapi函数），这样的处理方法很容易就会被忽略。（比如说，你经常检查winapi函数的返回值吗？）所以，出现问题的可能性并不小。由于以上的原因，我们需要一个这样的机制，它能让我们不能忽略这些错误，而且，这个机制应该能被我们控制和自定义的。在这样的需求下，异常处理机制出现了。需要一个特殊的错误类型吗？简单，定义一个新的异常类型就行了（和定义一个类的方法差不多），然后抛出（throw）它。下面这个例子说明了这一过程。

　　例1：

　　//------------------------------------