c#调试三部曲

我们在做程序开发时,难免会遇到错误异常。如何快速地找到出错的地方、分析错误的原因以及找到解决问题的方案,是许多初级程序员困扰的问题,这也正是经验的宝贵之处。下面我将简单介绍在Visual Studio中调试以及一些高级的调试和常见的错误。

  PS:如无特别说明Visual Studio均指Dev10即Visual Studio 2010。

  入门篇

  假设你是有着.Net平台的程序员,并且使用Visual Studio 做为开发工具。

  断点:最简单的一种,设置一个断点,程序执行到那一句就自动中断进入调试状态。设置断点,在你觉得有问题的代码行,左侧单击,会出现红色的红点即断点。

 

  启动调式:按F5,或者菜单栏---调式---开始调试,或者工具栏的图标

 

  快速监视:快速查看变量或者表达式的值,也可以自定义表达式进行计算

 

 

  单步执行

  有三种,一种是每次执行一行(F10);一种是每次执行一行,但遇到函数调用就会跳到被调用的函数里(F11);一种是直接执行当前函数里剩下的指令,返回上一级函数(Shift+F11)。

  还有一种后悔药,设为下一句(Set Next Statement),即下一句会被执行的语句(右击设置或者快捷键:Ctrl+Shift+F10),但要注意在调试与数据有关的时候,设置下一句有可能会报异常。如在调试向DataTable中添加行的时候,已经存在的行不能重复被添加到DataTable中。

  监视

  调试器可能会自动列出一些相关变量的值,但是你可能还关心其它变量的值,可以添加对这些变量的监视。还可以监视一个表达式的值,比如a+b。但是,这个表达式最好不要修改变量的值,比如监视a++都会导致监视时修改了a的值,影响了程序的运行结果。

调试技巧篇

  使用快捷键会大大提升我们的调试效率,常用的调试快捷键:

  F5 启动调试

  F10 执行下一行代码,但不执行任何函数调用。

  F11 在执行进入函数调用后,逐条语句执行代码。

  Shift + F11 执行当前执行点所处函数的剩余行。

  Shift + F5 停止运行程序中的当前应用程序。可用于“中断”模式和“运行”模式。

  拖动断点(感谢 圣殿骑士的提醒)

  在调试中,我们可以拖动断点,使得程序运行到我们想要运行的地方。通常是用来验证这段代码对程序的运行结果有没有影响的。因为我们拖动代码,则被过滤的代码就不会执行,将它跟原来的相比,可以看出去掉这段代码有什么影响

  条件中断

  假如你写了个for循环,而且循环的次数比较多,如下代码,现在我们知道在i=50的时候会有异常,那我们不可能按50次F5去调试这代码,不然这效率......

private void ConditionDebug()
{      
for (int i = 0; i < 100; i++)       {           
if (i==50)          
{        
//some error code here    
Console.WriteLine("i=50 here");          
}      }  }

  我们可以直接利用vs提供的功能修改变量i的值,一开i=0,即刚进入for循环中,我们设置将i改为49并回车,再调试一次,会发现i=50; 如下图

 

  当然我们也可以直接在代码里写代码以达到这个目的,代码如下

private void ConditionDebug() 
{             
for (int i = 0; i < 100; i++)             
{  
System.Diagnostics.Debug.Assert(i != 50);                
if (i==50)                
{         
//some error code here          
Console.WriteLine("i=50 here");                
}              }  }

  使用了调试中的Assert(断言),当执行程序后会弹出如下的提示框,点击Ingore(忽略)即可

 

Immediate Window

  Immediate window在调试的时候计算表达式的值、执行语句、打印变量的值等。我们输入命令(注意一定要以“>”开头),会有智能提示,而且命名都是自解释型。

 

  如,我们现在想要知道i的值,可以输入命名>Debug.Print i(也可以简单的使用>? i),如下图

 

  Immediate window还有更强大的用法,计算方法的返回值(如果有的话)

  如果有这个的函数

int MethodValue(int a) 
{            
if (a==1)             
{                 
return 1;          
   }           
  else         
   {           
      return 0;     
        }  }

  我们可以使用Immediate命令 >? class.Method(args) 去调用这个方法,如下图

 

  其中p是当前类的实例(因为MethodValue是类的方法,注意?和表达式之间要有空格)

  对于一些实时性很高的程序(如socket)使用 Debug.Write()把错误写到日志文件中,.Net可以将Debug信息写到你指定的文件中,记住,写进出的信息不一定是出错的信息,也可以是你的程序的运行的一些重要信息,当你调试过程中发现某个模块出了问题,但是不能决定位置,那你就可以使用这个方法,如果是一天才出一个错误,那你就更要使用这个方法。

  实例篇

  涉及到WS(WebServices)的调试

  在基于WinForm的实际开始开发中,我们往往采用WS用做数据的传递,我们在前台获取收集数据,通过WS将数据传递给后台,后台做相应的业务逻辑处理后,会持久到数据库中。而往往我们又会在WS中写一些相关的代码,如身份验证、日志记录、提示信息等,怎样去调试这些代码呢。

  涉及到JavaScript的调试

  许多程序员为调试JavaScript感到困惑不已,因为没有一款很好的调试工具。一些人喜欢使用FireBug来调试JavaScript,确实是一个不错的选择,Firebug提供了许多的JavaScript信息,是一款不错的调试JavaScript的工具。下面我将会介绍如何使用Visual Studio调试JavaScript,Visual Studio中调试JS跟调试C#差不多,都是设置断点,不同的是我们在查看元素值的时候需要注意点。

涉及到Ajax的调试

  现在ajax已经十分的流行,但是随之而来的即调试困难,大部分初级程序员不知道如何有效地从前台调试到后台代码,以至出了很多不完善的ajax应用。

  下面以一个简单的实例来介绍如何使用Visual Studio调试JavaScript。实例是使用Ajax验证用户登录,如果验证通过,则提示“登录成功”,否则提示“登录失败”。

  下面是主要的代码,我们使用jQuery来实现ajax,并且在后台文件中故意出错。

  正确的用户名和密码是admin和1

  调试方法如下,在后台入口处设置断点,然后在前台js中调用后台的方法处设置断点,然后按F5启动调试,当我们输入用户名、密码后,点击登录后会发现,前台断点被触发了。

 

  按F5继续调试,有时候会跳到jQuery的源码中,不管他,继续F5,会发现执行到后台中的断点中,如下图

 

  而后台代码的调试是十分简单的。(PS:有时候无需在前台设置断点也可直接进入后台的调试,如何不行的话,在前台html文件或者aspx文件中认为有可能出错的地方设置断点,一步步调试)

  一些调试中出现的常见错误(会陆续更新):

  1. 我们调试到某一句代码的时候,突然莫名奇妙的跳出来了,其实是刚刚执行的这一句话有异常,我们可以使用try…catch进行异常捕获,看看异常原因是什么,然后做相应的处理

  2. 在ADO.NET,我们会使用ds.Merge()方法进行合并内存表,如果有异常的话,一般有以下三种情况

  A.其中一张表中有两行一模一样的数据,包括主键

  B.这两张表的结构不一致

  C.两张表中某个字段的类型不匹配,如字段age在A表中式string,而在B表中确是Decimal

  断点篇

  命中次数(Hit Counts)

  右击断点,可以设置Hit Counts(命中次数),会弹出如下的对话框

 

  当条件满足的时候断点会被命中(即即将被执行),这个命中次数是断点被命中的次数。默认是始终break,选项有如下的几种:始终break;当命中次数达到多少次时break;当命中次数是多少的倍数时break;当命中次数大于等于多少的时候break。

 

  于是在上篇中的条件也可以这样实现,设置命中次数等于50的时候break,按F5后,断点被触发,此时i=50。 

断点过滤器

  我们可以限制断点在特定的处理器和进程中。可以设置机器名、进程id、进程名、线程id、线程名中的某些条件来过滤一些断点。

  注意:ThreadId需要特别说明一下,ThreadId并不是托管程序中,.NET 框架中System.Threading.Thread.ManagedThreadId,两者不能等同。简单来说,ManagedThreadId是线程在CLR中的标识符,而ThreadId却是线程在操作系统中的标识符。因此ThreadId需要从调试器中的“Threads”窗口中获取。

  断点条件

  我们可以设置断点达到的条件,如下图,我们设置表达式为i==5(注意是判相等,而不是赋值的等于),按F5,断点再次被触发,此时i=50。

 

  还有一个选项是已经被改变,则里面条件是具体的变量,如我们的代码如下

private void ConditionDebug()
{
            int hitCount = 0;
            for (int i = 0; i < 100; i++)
            {
                if (i==49)
                {
                    hitCount = 1;
                }   
            }
            Console.Write("Hit Count={0}", hitCount);
}

  我们在代码里如果i==49,就将hitCount的值改变,同时设置断点的条件为

  则当断点再次被触发的时候此时i=50。这个通常被用在找变量的时在什么时候发生改变。

  断点的位置

  可以设置断点的位置,如下图,设置程序到达那个文件的第几行第几个字符时触发断点。

 

  断点触发时…

  我们可以设置断点到达时做一些其他的事情,如打印消息,运行一个宏。

 

自定义调用堆栈

  堆栈跟踪时vs一步步执行你的程序是对当前的方法调用继承关系的直观显示。在调试程序时,我们会经过一个又一个方法,包括方法的嵌套调用。堆栈跟踪会对这当中的每一层方法作出记录。选择“调试-->窗口-->调用堆栈”,或者是快捷键Ctrl+Alt+C就可以看到当前的堆栈跟踪状态。这里会将每个方法单独显示为一行,并且带有行号和参数值。每一个新的方法调用被称为堆栈帧。

 

  堆栈跟踪是广为人知的调试工具,它的优点在于你可以双击任意一行跳转到程序中该层调用方法的代码。于是你可以看到程序是如何执行到这一位置的,同时可以看到方法接受的参数值。并且可以使用Ctrl+C将一个或者全部堆栈帧复制到剪贴板,并将这个方法的调用信息发送给工作伙伴。

  Start external program:调试的时候启动内部程序

  Start browser with URL:调试的时候打开URL地址

  使用Trace.axd调试ASP.NET

  在以前asp时候,我们为了查看某个变量的值,通常会使用Response.Write方法。可能现在许多ASP.NET程序员也习惯在后台使用Response.Write方法将变量的值写出来,其实微软提供了很好的调试工具,即Trace.axd。它的功能主要是:配置 ASP.NET 代码跟踪服务以控制如何收集、存储和显示跟踪结果。

  关键的几个选项:

  1、localOnly 默认为false。这个很好理解。如果为true,只在本地输出跟踪信息。

  2、enabled 是否启用跟踪。

  3、pageOutput  指定在每一页的结尾是否呈现跟踪输出。如果是 false ,则只能通过跟踪实用工具访问跟踪输出。

  4、requestLimit  指定在服务器上存储的跟踪请求的数目。最大为10000,默认为10

  5、traceMode  指定显示跟踪信息的顺序。SortByCategory或 SortByTime(默认)

  下面以一个小Demo来说明怎么使用Trace.axd来调试ASP.NET

  1. 建立一个Web项目,取名为WebTraceTest

  2. 编辑web.config文件,添加trace节点(在)

  内容如下:

<trace enabled="true" localOnly="true"
pageOutput="true"
requestLimit="15"
mostRecent="true" />

  3. 新建一个页面,取名为Test.aspx,在里面增加一个文本框和一个按钮(都是服务器端的控件)

  按下F5,开始调试,会发现出现如下界面

 

  5. 在文本框中输入文字,如Alexis,点击按钮,会发现Form Collection中会有详细的信息,如下:

 

  说明:使用Trace.axd我们可以获得以下信息:

  Request Details:请求的详细信息

  Trace Information:跟踪信息

  Control Tree:控件树

  Session State:会话状态

  Application State:应用程序状态

  Request Cookies Collection:请求Cookie集合

  Response Cookies Collection:响应Cookie集合

  Headers Collection:标头集合

  Response Headers Collection:响应标头集合

  Form Collection:窗体集合

  Querystring Collection:QueryString集合(即Url中?后面的字符串的信息)

  Server Variables:服务器变量

Visual Studio与一个运行中的进程连接

  当你按下F5对程序开始调试时,VS.NET会对项目进行生成(如果有必要的话)并以调试模式启动程序。也就是说,只要项目位于debug版本的程序集中,VS.NET就与运行得程序之间建立了连接,以便对断点等与调试相关的方法作出反应。

  不过有些时候,我们需要或者想要对正在运行得Visual Studio之外启动的进程进行调试。当进程位于debug版本的程序集中,这是可以做到的。

  1. 选择“工具—>调试进程”列出所有正在运行得程序,如下图

 

  2. 选择自己感兴趣的进程,点击连接,此时Visual Studio自动切换到了调试模式。

  3. 打开Progress窗口,发现我们刚刚选择的进程在列表中,如下图

 

  这一技巧可以让你对Windows服务进程进行调试。编写Windows服务进程时,你无法按F5启动调试,因为它们必须先通过管理工具安装后启动才能运行。如果你在调试模式下生成并安装服务程序,就可以使用这一技巧进行调试。

  而且你可以对SQL存储过程使用同样的方式进行调试。如果你安装了SQL Server调试组件,并且有足够的权限,就可以连接到SQL Server的进程,并在服务器中为存储过程设置断点来一步步执行。

  调试Visual Studio中的多个项目

  在实际开发中,我们往往分了许多层,有许多的项目集合在一个解决方案下。我们可以右击要调试的项目选择“调试-->运行新实例”来实现调试这个项目。我也可以右击解决方案,选择多项目调试,如下图

 

  我们还可以设置项目的期待顺序。在客户端/服务器(CS结构)程序中,我们可以使用这一方法来确保服务器端程序在客户端程序之前运行。

  只在特定类型的异常时中断

  一个健壮的程序会在运行时处理所有可能出现的异常。不过开发者在调试复杂的程序时会觉得这样有些麻烦。因为所有的异常都被处理掉了。在出现任何异常时,Visual Studio不会再进行处理,或者中断代码来对用户作出提示。

  幸运的是Visual Studio有个选项可以让开发者指定他们关心的异常类型。选择菜单栏à调试à异常,或者使用快捷键Ctrl+Alt+E。如下图

 

  我们可以看到一个树状结构列出所有VS可以监视到的异常。

  后面的两个勾选框的意思分别为是否被抛出和用户是否不处理。

原文地址:https://www.cnblogs.com/panshengqiang/p/2835168.html