博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【C#】#if DEBUG 与 如何更好更快的debug
阅读量:5346 次
发布时间:2019-06-15

本文共 3403 字,大约阅读时间需要 11 分钟。

本文转自【】

一、捕捉异常(try / catch /finally)

    这个我不用说,大家都清楚它的作用,就是捕捉程序中所有可能导致错误的异常,然后加入自己的处理措施,并且使程序继续运行,而如果不捕捉异常的话,程序将会终止,简单的把错误信息发送给客户。
所以,在进行所有可能出现错误的操作时都应该捕捉异常,象下面这个例子,捕捉数据库操作可能出现的异常。
  

///  /// 取得数据库连接 ///  /// 数据库名 /// 输出参数,空数据库连接         public void GetConnection(string a_strDatabase , out SqlConnection oa_objConnection)         {
oa_objConnection = null ; string strConnStr = ""; try {
strConnStr = "server=" + m_objIni.GetProperty("server") + ";uid=" + m_objIni.GetProperty("uid") + ";pwd=" + m_objIni.GetProperty("password") + ";database=" + a_strDatabase ; oa_objConnection = new SqlConnection(strConnStr) ; oa_objConnection.Open() ; //log it m_objLog.Write("数据库连接ok") ; } catch(SqlException e) {
//log it m_objLog.Write("数据库连接出错" , e) ; #if DEBUG Console.WriteLine(e.ToString()) ; #endif//DEBUG throw(e) ; } } }//end class

        
二、条件编译
    java不提供条件编译,这是我觉得java不好的一个原因之一,所以在写java时都是自己写一个类来实现条件编译。那么,什么是条件编译呢?就是当符合某一条件时编译,不符合时就不编译,这就方便了debug。我们经常遇到这种情况,在某一过程或方法里我们想要知道某个变量的值,比较常用的方法是在页面或控制台输出这个变量的值,已确定是否是自己希望的值,但如果没有条件编译的话,但当你发布发行版本时需要手工删掉这些输出语句,费时、费力,并且容易出错,而如果有条件编译,那就方便多了。看下面这个例子:
        

///  /// 初始化 ///          private void Initialize()         {
try {
m_objConnManager = new ConnManager(m_strIniFilePath , "./config/newsdata.ini") ; log = new Log("./logs/newserver.log") ; } catch(Exception e) {
#if DEBUG Console.WriteLine("初始化" + e.Message) ; #endif//DEBUG throw(new Exception("初始化" + e.Message)) ; } }

注意到其中的#if DEBUG那几句吗?它的作用就是当DEBUG时,在控制台输出异常信息,以便你马上知道出现什么错误,而当不是DEBUG时,那句就不会被编译。
   
三、断言(Assert)
       断言真是一个值得大书特书的好东西,但可惜的是80%的程序员尤其是web程序员不用它,甚至根本就没听说过。很难给断言下一个定义,如果要详细说它的好处,简直都可以写一本书了。简单地说,断言就是在应该是正确的地方加一个判断已确定它真的正确(这话有些拗口,下面我会详细解释),它的作用就是确保你的程序按照预计的目标正常运行,并且能够帮助你迅速定位错误原因。断言的机制很简单,就象c#里的断言方法System.Diagnostics.Debug.Assert的定义,判断一个条件是否成立,如果不成立的话就显示一条信息。看起来很简单,真的能起那么大作用吗?让我们看下边这个例子。
        

///  /// 存取m_strID的属性 ///          public string ID         {
get {
return this.m_strID ; } set {
#if DEBUG //断言 Debug.Assert(value.Length % 2 == 0 , "分类id长度必须为偶数") ; #endif this.m_strID = value ; } }//end method

    这是个很简单的方法,就是为了存取m_strID这个成员变量的值,这个m_strID是个利用编码规则实现树形结构的字符串成员变量,就像这样:010213,两位为一间隔,通过它的长度和编码规则可以很容易得到它位于第几层,它的父节点的id等等。因为两位数为一间隔,所以这个字符串的长度必须是个偶数。
       看到Debug.Assert那句吗?它的作用就是判断这个字符串的长度是不是偶数,如果不是,则谈出一个对话框来显示"分类id长度必须为偶数"。或许你会说看不出它有什么作用,不就是判断一个值符不符合要求吗。本来这个程序都是你自己写的,所以你给这个m_strID赋值时应该知道这个长度为偶数的限制,一般情况下应该都是正确的,好,现在让我们假设这么一种情况,由于某种原因,你忘记了这个限制,而把一个长度是奇数的字符串赋给这个变量,而这时虽然有问题但程序并不报错,继续运行,当过了很远时,这个错误显露出来,使整个程序崩溃或最终结果不正确,这时即使程序报错也是在离产生这个错误的真正原因很远的地方,或者干脆就不报错,这是你要找到错误的原因就很困难了,可能要花费几小时甚至几天的时间,而如果当时你加了断言,运行到这里的时候就会终止,告诉你错误的原因,也就避免了后面出现的问题以及你为纠正这个问题所付出的时间和精力。
    怎么样,现在是不是对断言有了一定的了解,并且有一些兴趣呢?试一下吧,慢慢的你会感受到它的威力。另外需要说的一点是断言是为了辅助deubg的,而不是进行错误处理的,所以一般把它和条件编译结合使用,只有当编程、测试时才使用断言,而当发行正是版本时应该去掉断言,因为毕竟它是要影响效率的。
四、日志(log)
    程序记不记日志恐怕是区分传统程序员和web程序员最好的标志了。大多数应用程序都记日志,而几乎所有的web程序都不记日志,呵呵。其实日志也是一个特别有用的东西,如果不记录日志,那很可能系统发生了什么、出现什么情况你都不清楚,尤其是时间一长,更容易出现这种情况。所以,养成良好的习惯,让你的程序写log吧。
    当然,除了上述这些,还有很多东西,如跟踪(trace)单步调试等等,你可以自己看一下资料。
方法我都讲了,用不用就是你的问题了,呵呵。

转载于:https://www.cnblogs.com/XL-Liang/archive/2011/12/23/2299049.html

你可能感兴趣的文章
DataGrid 点击 获取 行 ID
查看>>
git 使用
查看>>
边框圆角方法
查看>>
asp.net WebApi自定义权限验证消息返回
查看>>
php中eval函数的危害与正确禁用方法
查看>>
20172315 2017-2018-2 《程序设计与数据结构》第十一周学习总结
查看>>
MySQL添加、修改、撤销用户数据库操作权限的一些记录
查看>>
关于谷歌浏览器Chrome正在处理请求的问题解决
查看>>
Git核心技术:在Ubuntu下部署Gitolite服务端
查看>>
平面波展开法总结
查看>>
建造者模式
查看>>
ArraySort--冒泡排序、选择排序、插入排序工具类demo
查看>>
composer 安装laravel
查看>>
8-EasyNetQ之Send & Receive
查看>>
Android反编译教程
查看>>
List<string> 去重复 并且出现次数最多的排前面
查看>>
js日志管理-log4javascript学习小结
查看>>
Android之布局androidmanifest.xml 资源清单 概述
查看>>
How to Find Research Problems
查看>>
Linux用户管理
查看>>