这篇文章,我将从最基本的开始谈起。但期望可以涉及更广的层面,而不只仅是为你的程序除错(debug)。你将会看到,我认为除错(debugging)这个字的全部意义,并不只是通过ide的内建机制来运行的。我期望在这篇小小的文章结束时,几乎每个读者都可以学到至少是一件新东西,并把它藏到你的兵器库中。记住,你程序中的错误(bug)越少,你的最终用户对你的程序的感觉就越好;你对错误(bug)的处理越好,用户们发现错误(bug)时就越乐于告诉你以便你改正错误。好了,现在系好安全带,戴上护目镜,让我们开始一段疯狂的路程!
书写洁净的代码
首先而且或许是最重要的一点是书写洁净、可读的代码是极其重要的。能够在写完一段代码后回顾一下并给它加上注释来说明这段代码用来做什么和为什么这么做,将会省去你当前跟踪代码的无数个痛苦的小时。或许你会多花一点时间来书写,但当你花过n小时来跟踪那些难以捉摸的bug时,你就会同意多花点时间来让程序代码可读是多么值得了。(你本可以很轻易完成除错的)。假如没有这么做过,我建议你停下来,读读另一篇scott的出色文章-代码的风格(大家需要的话,将会尽快翻译)。
使用异常及异常处理能力
现在进入下一步,这仍然是基于代码的步骤。(除了在极少数的情况下,你不能老是使用系统内建的除错器,所以知道其他可以找出这些麻烦的虫子的办法总是个好主意)。本步骤完全是关于如何做到,更重要的是处理好在你的窗体出现异常时系统扔给你的(产生的)错误。在c++标准得到认可前黑暗的旧日子里,应用程序通常会通过返回值来发出错误信号(这种方法在ole和一些winapi函数中仍在使用)。很明显,你可以很轻易的忽略这些(事实上也是经常的,我的意思是你经常反省一个winapi函数的返回值吗?)。
所以他们决定….,okay,我们需要一个新的机制,一个你不能忽略的。但你可以处理,定制(自定义 customize)。异常就此出现了。想要一个非凡的错误类型标志?轻易的很,定义一个新的异常类型(不过是一个类,没别的),抛出来(产生这个异常)。完了。
例子:
class myexception
{
public:
ansistring imessage;
myexception(ansistring message) { imessage=message;}
};
throw new myexception(“test exception message”);
就这么简单!(当然不是很完全,我会很快加上的)。漂亮而又简单,并且非常轻易定制来满足您的需要。okey,你会问到:“我能产生异常了,但如何处理它们?我的意思是,我想在第一时间(位置)从我的代码中排除异常!”这当然很轻易做到,实际上还很轻易定制呢!标准委员会为我们定义了try {/* code */} catch (...) {/* code */ }机制,跟异常机制一样,它完全可以定制来满足您的需要!只需把您的执行代码段放在try模块中就行了,您还需要一个catch( ) 或 __finally 模块来告诉程序(假如)得到一个异常的时候作什么。现在就是你这么做的好处,你定义了一个类class类型并且输入变量来捕捉异常-通过声明catch( )。(在前面的例子中,该当是这样-catch(myexception &e) { /*在这里书写捕捉到异常后的处理代码*/})为了让这个系统更有力,你可以建立完整的子类继续树。这样当你捕捉基类时你可以捕捉所有从这个基类继续的异常类型(vcl中一个很好的例子就是所有的异常都是从exception类继续而来的,所以catch(exception& e) 将捕捉所有的vcl异常,当然包也括您所产生的。但eSocketerror除外,见xiphias在 的howto (若你不喜欢e文的话,我会尽快翻译)。记住这个想法,我会在当前另一个步骤具体说明)。要让它再有力一些的话,标准委员会决定包括如下的声明catch(…) ,没错括号中就是三个点。此声明答应我们捕捉任何异常,我的意思是所有的异常。还想再有力一些?当然可以,你可以用附加的catch( )声明,跟if..else if…的样子差不多。这里要牢牢记住!假如你捕捉到了一个异常类型,那么当前就它不会被再次捕捉到了!所以先看下面的代码…
try
{
// 程序的正常运行代码
}
catch(edbengineerror &e)
{
// 处理基于数据库引擎的错误
}
catch(eexternalerror &e)
{
//通常处理基于windows的错误
}
catch(exception &e)
{
// 处理所有其他的vcl错误
}
你可以看到,这里按照 "是edbengineerror吗? 是->处理,不是?->继续捕捉" "是eexternalerror吗? 是-> 处理, 不是?-> 继续下一次捕捉" 等等… 这样的顺序排列。
接着还有更多的内容。假如你期望对某个异常做些什么,又不期望异常就此消失,你可以重新抛出(产生)这个异常。它将继续向后寻找新的catch()过程来处理它。我不能说我经常这么做。但最好该当知道,就象“抛出”一样简单。就是这样,throw将带着已经被你处理过的异常继向后寻找另一个catch来处理它。
最后而不是最不重要的 (这部分不包括在标准规范中,倒更象是borland专有的增加版)就是 __finally 声明,使用一个 __finally{ } 模块,你可以指定不管有否异常产生都将运行的代码。这里是清除你通过new方法分配的局部变量及将所有该当设定回正常状态的标志复位(例如将一个等待状态的鼠标指针复位成正常状态)的最方便的地方。
呸,太多了!休息一下吧,有空可以看一看c++builder帮助中的exception类, (所有e开头的,你会注重到它们都是从exception类继续来的。这也是定制你自己的异常类的好练习!) 当你回来时,我们将进入下一步旅程。
使用记录(logging)机制
您不可能总是使用除错器来除虫,有时你没法依靠内建除错器的力量,所以有时你将不得不求助于其他的除错手腕来调试程序。(典型例子如:nt服务、isapi/cgi程序、实时应用程序…等等)此时您将不得不求助于我们这样经验丰富的程序员才会谈到的老式的除错/调试技术。例如产生使用某种记录(logging)机制来看看程序的头巾下面究竟发生了什么的念头。幸运的是,有许许多多的现成的机制可以让我们的这项工作变得轻易些。这里我将谈到我所偏爱的三种方法,你也可以将您自己的方法Email给我,我会考虑加入这一部分。
okay 先说第一种,(调试/除错输出字串)outputdebugstring。幸运的是microsoft已经为我们实现了一个非常广泛的调试/除错子系统。包括实现您自己的调试/除错记录系统的机制。程序在一个调试/除错进程内运行的时候,outputdebugstring将它的参数(一个c string)输出到调试/除错器的输出上下文,若调试/除错器没有运行,outputdebugstring就被忽略。假如没有弹出消息的时候,outputdebugstring在终端上也可以很好的运行,当你分发给客户前别忘了移去它(通过 #ifdef debug…#endif’),程序可以运行的更快一点。“wow,又好又轻易!”你或许会说“但当程序不能在调试/除错器内运行时,该怎么办?”
请牢记,这只是我的观点,基于一种观念的评价,我个人使用gexperts的dbugint.pas界面来调试/除错。这是个非常优秀的独立的小程序。假如愿意,您可以将它分发给你的客户们。假如没有这么做,象outputdebugstring一样,假如没有安装,它实际上就什么也不做:)(它将注重终端是否已经安装在机器上)。要使用dbugint.pas的话很轻易,将它加入你的工程并加上 #include "dbugintf.hpp"(因为是pascal文件,你必须将它加入你的工程以便c++builder编译器生成hpp头文件。)然后你只需使用senddebug(“要送到记录中的字串”);或者你或许想更灵活些,还有senddebugex-增加一个消息类型参数来调用tmsgdlgtype(具体说明参考vcl在线帮助),sendmethodenter, sendmethodexit, and sendseparator 等等(十分自解释的名字)。只是别忘记加入必须的package包,若你打算将此终端(gdebug.exe)其给你的一些最终用户的话。gexpert可以从 获得并且是收费的。
第三种我要指出的是,这或许是最难的选择-实现你自己的记录控制台。可没有你想的那么简单!你或许首先会想到“扔个richedit控件在form上,将它设为只读的,然后开始记录,对吗?” 错!理论上挺好,但实践呢,使用richedit控件来记录将降低程序的运行速度、使内存破碎,丢失、通常会在10分钟内使整个机器慢下来!!(要说明白为什么得花上点时间才行,但我向你可以保证)。所以你所需要的是计划好你的记录机制的需要,并开始计划一个定制控件若你想要个彩色的图标的话。还有一个选择,需要做点工作,但可是非常有效。就是使用一个listbox控制来记录,并将style属性设为lbownerdrawfixed,这样句柄将会自绘。(这也是gexperts和它的gdebug console所做的)。要做许多工作,但哈哈,假如你想做…
结合使用记录机制与类的异常处理机制
现在进入下一步:)(跟你打赌你从未意识到设置一个优秀的调试/除错系统需要做如此多的工作!)你不用总是预料各种偶然的异常会发生什么,而且绝大多数时候当程序经过大量的除虫测试(尽量攻击程序,试图让它崩溃)后,你根本不用担心这些。下面这个技术,我建议任何组件开发者第一次在ide中测试一个新组件/新代码时该当完全遵照。因为在ide中一个异常会带来很多问题,有时甚至重启ide也无济于事(我自己已经这么做了)。其实也很简单。在您代码的每个函数前,或者至少在所有主要的函数前后加上:
try
{
前端代码
}
catch(exception &e)
{
senddebugmessage(“exception caught in classname::functionname of type:” +e.classname()
+” with the message:”+e.message);
};
(并用函数的类名及函数名代替字串中的classname和functionname)。这样你很快很快就知道异常发生在何处,也不用你强行关闭ide啦。
okay,是时候回顾一下了。classname()方法是如何帮助我们的?不想每次都只得到一个“exception“串就完了吧?难道是因为将e声明为一个异常?不对。这是vcl比较酷的部分,任何从tobject继续来的类能够主动知道其自身的类型、其基类的类型、等等许多有趣的信息,你可以察看tobject的帮助。所以尽管我们使用的是exception &e,e.classname()将会找出我们得到的异常的实际的类名(译者注:c++的多态性)。这些好处的代价就是可执行文件的体积更大了,几乎所有的c++builder/delphi程序员都会发现这一点。(no pain, no gain)没有痛苦,就没有收获.他们说….
xiphias增加了tstringlist的addingline方法,savetofile方法是另一种记录(logging)的有效形式。最后该当保证你的应用程序总是写记录文件(logfile),或这每次捕捉到异常时重写记录文件。
处理您代码外产生的异常
现在的步骤是我们开始学习基于ide的除错器之前的最后一个基于代码的步骤。但或许在有严峻错误发生时,对装饰应用程序来说这是最重要的步骤。举例来说,这是显示一个包括错误具体内容的对话框理想的时机。这时弹出在屏幕上的对话框可以方便最终用户能够向您报告错误。我敢保证您痛恨“oh,有个什么框子上说在什么地址发生了个什么异常错误”这样的报告。其实完全可以很轻易的实现更好的情况,也不会限制你打算如何处理它。第一步是在你的主窗体(例如:工程的主动创建窗体列表中的第一个form)中创建一个象如下这样的函数:
void __fastcall Applevelexceptionhandler(tobject *sender, exception *e)
{
}
然后加入合适的代码来显示错误(e->message),错误类型(记住e.classname(),只要此时才是它的e.classname()),和联系您的具体方法及其他你想加上的任何东西。第二步当然是将它与系统挂钩,这在c++builder里很轻易实现:
application->onexception=applevelexceptionhandler;
将上一行代码加到form的 oncreate 事件中。不要吝啬!你加了这一行后几乎可以保证不会错过任何异常,而且无论哪里异常处理失败时它都会出现在你的眼前!
你的回合
现在你已经得到所有你刚才学习的有用的信息了。是时候开始把它们加到你现在的工程里去了,否则就忘掉吧,要不然,就把它变成编程习惯的一部分。这是你的自在!
在这个系列的下个部分,我将讨论内建除错器的使用,来看看你的程序运行时都干些什么,如何单步跟踪代码、设置断点、察看变量、和会把新手们吓的人事不醒的所有其他有趣的工具。直到这里,您的bugs或许只是小虫子了吧。
Okay,(再小小预备一下)现在开始追踪、搜索经过前次的努力后仍然躲在代码中的bug的时候了,也就是开始跟踪前一篇文章代码里标记过的bug/异常。首先是预备阶段。
调试可执行程序前的预备
在我们开始调试可执行程序前,我们需要确保一些设置在大多数情况下的正确性。我将会一条接一条的过一遍,并简单解释一下为什么必须那样做。(假如您对有些东西感爱好的话,按下帮助按钮,会有许多更详尽的内容)。现在就开始吧,先打开Project|Options选项。
工程选项
首先我们在"Compiler"(编译)标签处停下。您只需简单的单击"Full debug"(完全调试模式)按钮,我们所需的绝大多数的其余设置就已经搞定了。将"Code opTIMization"(代码优化)设为"None"(无)总是件好事,这样做实际上告诉编译器:所有的事情都已做好,只需产生气器码就行了。而不要为了提高一点点运行速度尝试进行其他的智能优化。(当然,一切都完成之后,您可以打开此项。)这样做的好处是大大降低了我们调试的难度。因为程序中的代码与我们书写的一样,没有被编译器优化过。在"debugging"(调试)面板中,将"Debug information"(调试信息)选上(点一下),并且必须设置为"Line number information"(行数信息)。我还建议将"Disable inline expansions"(禁用内联扩展)一项选上。内联扩展对发布的代码来说很好,但调试时最好还是关掉此项,他只会让您更头痛。
然后是"Pascal"标签,尤其在您的工程里连接了Pascal单元或使用了基于Pascal的VCL控件时(若您拥有其Pascal源码时,编译器会主动使用此节中的设置重新编译)。这里您必须将"Optimization"优化选项禁用,然后通常我会将"debugging"(调试)部分的所有选项选上(打钩)。
接下来是"Linker"(链接)标签,我们需要选上"Create debug information"(生成调试信息)。"Use dynamic RTL"(使用动态RTL)以及"Don’t generate state files"(不要生成状态文件)是造成麻烦的选项。我通常都会使用状态文件(这样答应增量链接,但会在编译目录下产生一个4倍于可执行程序或更大的文件),换个角度来说,这样会增加链接大工程时的速度。而使用dynamic RTL本身就是个争论,尚有很多赞同和反对的讨论。
下一个是"Directories/Conditionals"(路径/条件)标签。在这里我们想要设定"Directories/Conditionals"(调试源路径)的值。我们永远都应将此处设定为$(BCB)sourcevcl,但是假如您有任何其他的组件附加的话,通常将它们的路径也加上是个好主意(路径与路径之间用”;”分隔或者您可以用按下…按钮弹出的对话框来设定它们)。
最后也是最重要的设置是在"Packages"(程序包)标签上。根据所有恰如其分的调试经验您必须禁用"Build with runtime packages"(带运行时程序包编译)。这么做的原因是程序包本身不包括而且不能包括调试信息。这样做,或许不利于您跟踪标准的VCL代码,例如想看清楚VCL函数y中参数x是如何起作用的时候。但是大多数时候,您这么做将会发现调试器将您的绝大多数“症状”归结给VCL,尽管“病因”就在您的源代码中(或在其他的组件中(这已经在我们所有人身上发生了))。一旦您发布您的正式版本时,您可以决定是否使用程序包。(译者注:程序包的本质是一个非凡的DLL,不带运行程序包(静态)编译可以让您的程序脱离Cbuilder独立运行。),但在调试时,请禁用掉。按下OK按钮,我们已经预备好啦。下一个对话框只需打开一次,但最好还是来反省以下我们在这里的设定是否正确。好了,打开”Tools|Debugger Options…”吧。
对话框最下方的"Integrated debugging"(集成调试器)选项是要害所在。确信已经打上钩。按下OK按钮预备编译可执行程序吧。我建议重新来一次彻底的编译(选择Project|Build All),假如您修改过您的设置的话(尤其是改变”building with packages”方式后)。这将保证我们的所有程序单元按照我们所期望的那样被编译。
设置断点并闯入可执行程序
象您所见过的其他任何一款调试器一样,C++Builder提供强大的断点设置功能。基本上,断点是指代码中的一个点,程序执行至此停下(与退出不同,这只是执行中的暂停)并将控制权交还给调试器。设置一个断点相当轻易。只需在您想要设置的程序代码行左侧的灰色槽形区域点击,您会看到一个红点出现,这一行也会变红。程序运行到这一点就会暂停,将控制权交还给调试器。
您或许会问假如我不想每次都停下来呢?当然可以,而且还很轻易做到,这取决于您暂停程序的标准是什么?(译者注:条件断点)。在刚才那个断点(红点)上右击鼠标并从弹出菜单上选择” Breakpoint Properties”(断点属性)。此处可以设定两种属性"Condition"(条件)和"Pass Count"(通过次数)。Condition(条件)属性太方便了。您可以利用if()语句输入几乎是任意的条件。但请牢记条件中的所有变量,对此断点都应是可见的。条件属性并未被编译器编译到执行程序中,而是在运行时,当程序运行至断点暂停后,反省断点的条件是否满足。条件为真,停下,否则让程序继续运行。另一个属性"Pass Count"(通过次数)也很轻易理解。断点将被通过Pass Count次后停下。结合使用这两个属性,在调试您的代码时,您可以设定非常严格的断点。
还有一件要牢记的是,当您在调试器中发生异常时,会以产生异常处的那一行代码上的断点的形式出现。这种情况很轻易制造。一旦您得到一个异常后应做的步骤我会在当前展示如何在堆栈中回溯并跟踪找出异常发生的真正原因(如引起异常产生的那一小片代码)。
另一个要牢记的提示是当您运行您的程序时,代码窗口左侧有蓝点的任意一行都可以设成断点。所有非法的断点将会变为红点中带一个黄色的小叉,这一行代码也会变成黄褐色。合法的断点则变为红点中带一个绿色的小钩。运行时,您可以设置/修改任意一点,断点立即生效而无须重新编译。
察看储存在变量中的值
一旦您的程序在您的断点处停下后,该做什么?有一件事您想做而且必须做的,那就是察看储存在您程序中的各种变量真实的值。这部分内容涉及的方面很多,您一定要坚持,忍受这些枯燥的东西。幸运的是当您看完这些,您一定会对调试器这部分最强大的功能有些新的理解。有许多种方法可以察看变量的值,主要要根据您的目的来决定。我会从察看当前函数的Local Variables(局部变量)开始把他们都讲完。
察看局部变量没有太多可以讲的。只需点击”View|Debug Windows|Local Variables”,或按下ctrl-alt-L将会弹出一个窗口,显示了当前函数的局部变量。窗口中的变量将会随您单步向下执行或回溯的函数体的更新而更新。
使用Watches(观察)
下一步您可以通过设定一个variable watch(变量观察)来察看程序中的变量。就象它的名称所表达的,观察一个变量并将其值显示在变量观察窗口中(点击"View|Debug Windows|Watches"或按下 ctrl-alt-W)。您可以通过两个途径来添加一个观察,第一种是在代码窗口中高亮选择您要观察的变量或表达式(是的!它可以理解并对绝大多数简单表达式求值,比如(i*j)+05 或者 SomeVector[i].Name)并右击鼠标,选择"Debug|Add Watch at Cursor"或按下ctrl-f5,就会加入观察窗口。假如必要,同时会打开观察窗口
您还可以通过在观察窗口的空白处双击来添加。这时会弹出添加watch对话框,"Expression"(表达式)域的意思无须多说,但另几个域我想解释一下,它们也同样方便。
"Repeat count"(重复值)用于您观察一个已知长度的数组变量(比如一个blah[50]数组)。您要将Expression(表达式)设为数组的名字(本例中是blah)。"Repeat count"设为数组的元素数量(本例中是50)。然后就会显示数组的每个元素(如:blah[0], blah, blah…)。
"Digits"(小数位数)用来设定显示十进制浮点数的小数位数的。下面的点选集合是用来强制设定变量的显示类型的(将无符号长整数显示为十六进制格式)。还有一点要非凡说明的是,假如您在watch窗口中用鼠标右击一个watch后的弹出菜单上会出现"Break When Changed"的选项,这将在变量上设定一个断点,在此变量发生变化时会暂停程序。
使用Inspectors(巡视器)
巡视变量是察看变量中的数据的第三种办法。也几乎是观察完整的类的数据的最佳方法。可以有两种方法来巡视一个变量。第一种是在local variable window(局部变量窗口)中,双击一个变量,将会弹出"Debug Inspector"(调试巡视器)窗口,里面显示了这个变量所有的"Data" (variables) (数据(变量))、"Methods" (functions)(方法(函数))和"Properties"(属性)。假如这是个简单数据,将会显示此变量的名称及其中的值。(译者注:假如是数组呢?真不错!)
您会注重到,Debug Inspector(调试巡视器)很象property editor(属性编辑器)。当然如此,更加重要的是,事实上您可以在运行时实时改变这些值!!!小心使用啦!改入坏值的后果会让您有说不出来的悲痛。巡视器的这个能力可用来快速测试(假设的)游戏关卡(译者注:似乎FPE,GM),而不用有编译-运行-修改-编译-运行的循环。
(举例巡视Form1)在properties(属性)页上,您将会看到某些属性实际上并没有显示其的值,而是显示了{read=,write=}。假如这些值可以被赋值的话,当您在此区域单击后,您会注重到一个"?"按钮出现在属性的右侧。单击这个按钮将会系统执行适当的函数来尝试取回属性的值。我们可以在这儿举个例子-就举Form1的MDIChildCount的属性吧。在MDIChildCoun的属性值区域上单击,在按下"?"按钮,哇,0(正是非-MDI的程序的指定值)。调试巡视器强大的能力并未到此为止。在巡视器的成员变量的适当区域双击可以打开成员变量的巡视窗口,提供与您开始打开窗口一样的能力。
巡视器窗口的另一个有用的功能是从对象继续的能力。这可以在通过在适当区域上右击选择"Descend"(继续)来做到。继续的后果是产生了一个新的变量。您会注重到顶部的下拉List box中的变量名称已经换成新的变量名了。您可以直接在ListBox中切换巡视的变量。这使得在对象的不同部分快速切换变得非常简单,而不会让大大小小的巡视器窗口烦扰您的工作空间。
有一点要牢记的是,假如您分开函数,或者分开变量的作用范围,调试巡视器会失去对变量的跟踪。若您需要再次察看的话,请重新设置巡视器。但是您在当前函数的代码中单步运行的话,巡视器会主动刷新。