【C#】#if DEBUG 与 如何更好更快的debug

【C#】#if DEBUG 与 如何更好更快的debug
一、捕捉异常(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）单步调试等等，你可以自己看一下资料。
方法我都讲了，用不用就是你的问题了，呵呵。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/sunnykaho/archive/2009/07/29/4391072.aspx