调试技术与异常处理.doc

3.1 跟踪与中间过程输出也许一个开发人员一半以上的时间都是在面对错误，所以好的调试/查错方法（工具）会减轻我们工作的负担，也可以让枯燥的DEBUG过程得以缩短。 VC开发环境所提供的调试环境是很优秀的，我们可以运用单步运行，设置断点的方法来查找问题所在。但是这种跟踪是非常耗时的，所以我们需要采用一些策略来让我们更容易的发现错误并对错误进行定位，所幸的是VC在这方面提供了强大的支持。在本节中我们先看看如何利用设置断点和利用TRACE宏来输出运行情况。 在VC开发环境中按下F9就可以在光标所在行设置断点，再按一次就可以取消该处断点。设置断点的意义在于在调试过程当运行到该行时回产生一个中断并返回到VC开发环境中，在开发环境中你可以查看各个变量的值。下面是我们用于测试的代码，前面有红色圆形的行表示该行设置有断点： 在调试过程中到达断点处你可以通过上下文变量窗口（Variables）观察该函数中的变量的值，如果需要观察未在该函数出现的全局变量或者类成员变量这需要将变量名添加到观察窗口（Watch）中输入变量名称。但程序编译完成后请按下F5键以调试的方式执行程序，当进入断点时VC开发环境会被自动激活，然后我们可以可以观察程序的运行情况。在调试过程中也可以添加和删除断点。如下图： 如果在运行过程中被观察的变量的值发生了变化则该变量在观察窗中会变为红色。 一般来讲设置断点有下面的技巧： 设置在进行判断的代码处，这样可以在运行时可以观察判断所依赖的条件是否正确。 设置函数开始处，观察该函数所依赖的变量是否都设置正确。 设置函数结束处，观察该函数对变量的改变是否正确。 设置进入其他函数前/后，通过黑盒法检查该函数功能是否正确。 对于循环体，应该先测试一个循环次数小的条件来检查循环逻辑是否正确，或者在循环的前几次设置断点，在运行几次后取消断点。 MFC中提供的TRACE宏可以帮助我们在程序调试运行过程中方便的输出调试信息。TRACE宏的定义为：TRACE(exp)，其中的表达式使用与printf相同的表达方法。例如下面的代码： void CSam_sp_31Dlg:OnTest2()static int i=5,j=50;char szDeb=debug string;TRACE(trace i=%d j=%dnstring=%sn,i,j,szDeb);i+=1;j+=5;在以调试方式运行程序是，当你点击TRACE按钮时会看到在调试窗口中输出了调试信息。 当程序在调试过程中执行到此处时会在输出窗口输入trace i=5 j=50n,string=debug stringn。使用TRACE宏可以让我们随时掌握程序运行过程中变量的变化情况，因为大多数情况下我们都不希望使用断点进入到程序内部，而只是注意运行中数据的值。 注意：不要采用TRACE宏一次性输出大批量数据或不间断输出数据，因为这样有可能会时程序运行变得非常缓慢，如： void test_trace_e(void)char *pszDeb=new char1024*1024;TRACE(%sn,pszDeb);/或者for(int i=0;isizeof(pszDeb);i+)TRACE(%cn,pszDebi);有一点需要注意的是，TRACE宏在只在调试（DEBUG）版本中起作用，而在发行（RELEASE）版本无效，所以不要在TRACE宏中进行对程序状态进行改变的计算或是调用对状态有改变的函数，例如： void yourClass:fun1()TRACE(%d,+m_iTick); /m_iTick状态改变TRACE(return value = %d,DoSomething();void yourClass:DoSomething()if(m_szOut = No)return FALSE;elsem_szOut=Yes; /状态改变reutrn TRUE;在调试中还有一种方法可以将对象内部内容输出到调试窗口中，这就是使用转储（Dump）。转储的实现要通过对象自身实现，在通过对象自身实现时有一个好处就在于可以输入内部受保护层成员。首先CObject类定义了虚函数：virtual void Dump( CDumpContext& dc ) const;当你从CObject中派生新类时你需要重载该函数，例如下面是个很简单的例子： class CMyButton : public CButtonpublic:CMyButton();CMyButton();public:#ifdef _DEBUG /由于转储只在调试版本中实现，所以使用条件编译virtual void Dump( CDumpContext& dc ) const;#endifprotected:CString m_szHotText;/当鼠标移动过显示的文字;CMyButton:CMyButton():CButton()#ifdef _DEBUGvoid CMyButton:Dump( CDumpContext& dc ) constdcn;CButton:Dump(dc);dcndump of CMyButton ntext is m_szHotText;dcn;#endif我们看到Dump函数接受一个参数为CDumpContext，通过该类可以将数据输出到调试窗口或是文件。CDumpContext重载了操作符，利用= 0); ASSERT(nLen m_pDocument = NULL); ASSERT(m_viewList.Find(pView, NULL) = NULL); 当ASSERT失败并引发异常时会有对话框谈出并报告发生该ASSERT失败位置。报错信息如：assertion failed in file in line 。 并允许你选择继续运行（Ignore）或是终止（Abort）程序。（当然选择继续运行是很危险的）选择Retry将会启动调试软件对程序进行调试。 此外我们时常可以看到下面的用法： ASSERT(pWnd);/检查指针是否已经赋值if( condition )ASSERT(FALSE);/强制抛出一个ASSERT异常此外还有一点，ASSERT宏只在调试版本中才会有作用，在调试版本中ASSERT(f)宏被展开为 do if (!(f) & AfxAssertFailedLine(THIS_FILE, _LINE_) AfxDebugBreak(); while (0)/ while(0)用来保证 ASSERT宏后面可以不跟随“;”如 ASSERT(f)与ASSERT(f);都合法/ THIS_FILE表示当前当前文件文件名，_LINE_为当前代码所在的行数而在发行版本中会被展开为：(void)0)所以对程序内部状态改变的代码不能够放置在ASSERT宏中否则在发行版中会出现不正常的现象，例如下面的代码： void yourClass:fun1()ASSERT(+m_iTick 5);ASSERT(DoSomething() = TRUE);void yourClass:DoSomething()if(m_szOut = No)return FALSE;elsem_szOut=Yes; /状态改变reutrn TRUE;如果希望合法检查在发行版本中同样起作用则可以利用VERIFY宏，VERIFY宏与ASSERT宏的VERIFY的不同在与VERIFY在发行版本中同样会起作用，但是使用VERIFY会导致非常不友好的用户界面。 对象的合法性检查需要根据对象自身的状态和一些对象自己的逻辑来作出判断，因此在对象外部（对象自身的状态和对象自己的逻辑外部可能无法访问）就无法正确判断，一个省时有效的办法是在对象内部进行检查，有对象自己负责合法性检查，例如下面的代码： void CObList:AssertValid() const CObject:AssertValid(); if (m_nCount = 0) / empty list ASSERT(m_pNodeHead = NULL); ASSERT(m_pNodeTail = NULL); else / non-empty list ASSERT(AfxIsValidAddress(m_pNodeHead, sizeof(CNode); ASSERT(AfxIsValidAddress(m_pNodeTail, sizeof(CNode); MFC利用成员函数 void CObject:AssertValid() const来实现对象的合法性检查，所以新的类必须是CObject的派生类，（在MFC中几乎所有的类都由CObject派生）由于C+的多态性派生类的AssertValid函数会被正确的调用。函数定义中的const表示该函数体中不能改变成员变量的值。 我们所需要做的就是重载AssertValid，并实现对象状态合法性的检查。在AssertValid我们不但可以检查数据的正确性，也可以对数据的逻辑性进行检查。例如一个盒子中的白球不能多于黑球，而且总数不能多于100： class CBox : public CObject.void AssertValid() const;int m_iWhiteBall,m_iBlackBall;void CBox:AssertValid() constCObject:AssertValid();/先调用父类的检查函数ASSERT(m_iWhiteBall=m_iBlackBall);ASSERT(m_iWhiteBall+m_iBlackBall AssertValid();/安全的方法是利用ASSERT_VALID(pView);与ASSERT宏一样，ASSERT_VALID宏只在调试版本中起作用。 利用合法性检查可以帮助我们在由于变量非法而引发异常方便的定位错误，所以在开发程序时多利用合法性检查并在必要的地方使用检查宏会帮助我们更有效的进行调试。 3.3 内存泄露检查在VC中提供内存检查的机制是跟踪new操作，也就是说所有的new操作都会被记录，如果通过new操作所分配的内存未被正常delete将会在程序退出时在调试窗口中显示出具体的内存泄露信息。 同样通过malloc分配的内存也会被跟踪，但是在显示时就不会知道实在程序中何处进行了malloc操作。先看一下下面的例子： void _tmain().char *pszNew=(char*)malloc(200);char *pszNew2=new char100;CString *pszNew3=new CString(test);./通过调试方式运行后并退出，可以看到调试信息中关于内存泄露的信息如下：Detected memory leaks!Dumping objects -strcore.cpp(118) : 37 normal block at 0x007702E0, 17 bytes long. Data: 01 00 00 00 04 00 00 00 04 00 00 00 74 65 73 74 G:temp2sam_sp_33sam_sp_33.cpp(42) : 36 normal block at 0x00770520, 4 bytes long. Data: EC 02 77 00 /对于CString *pszNew3=new CString(test);产生的信息G:temp2sam_sp_33sam_sp_33.cpp(41) : 35 normal block at 0x00770320, 100 bytes long. Data: CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD /对于char *pszNew2=new char100;产生的信息34 normal block at 0x007703B0, 200 bytes long. Data: CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD/对于char *pszNew=(char*)malloc(200);产生的信息Object dump complete.可以看到通过new分配的内存在显示信息时会报告出在那一个文件的那一行进行的new操作，而通过malloc分配的内存则仅仅是显示出内存泄露的信息而无法定位分配内存的程序位置。 此外如果需要在文件头部定义DEBUG_NEW宏才可以正确的跟踪new操作。具体代码如下： #ifdef _DEBUG#define new DEBUG_NEW#endif由于对new操作的跟踪只需要在调试版本中出现所以使用了条件编译。 我们可以看到VC所提供的检查内存泄露的方式是非常易于使用的，我们在开发程序时一定要注意内存的分配问题，特别是对于一些长时间运行的程序。下载本节代码 3.4 异常捕捉与处理在软件开发的过程中错误捕捉显得尤为重要，因为有的错误会导致软件功能失常，而有的却会造成破坏性损失。世上没有不出错的软件。软件的逻辑错误，人为操作的失误，运行条件的改变等等因素都会导致异常的出现。下面的代码是一个例子： char*