在线交流：Java编程Debug技巧-火龙果软件-UML软件工程组织

群组技术交流活动---在线交流：Java编程Debug技巧

火龙果软件工程技术中心报名咨询热线：北京 010-62670835 上海 021-50800371 深圳 0755-88849686

活动简介：

通过在线的方式交流关于《Java编程Debug技巧》的一些经验，，并对先前发布的视频<< Java编程Debug技巧>>进行答疑，答疑范围包括但不限于本视频，参与讨论者可以提出自己在“Java编程Debug技巧”中的相关问题。本次交流适用于一切对“Java编程Debug技巧”感兴趣的软件行业从业者。

请在讲座前首先通过网上报名>>>

此次讲座通过MSN群：uml@uml.com.cn，请在讲座前加入群组,加入方法“在MSN中作为联系人加”。

您可以先通过技术论坛说明感兴趣的议题和问题！

讲座简介

本课程将重点讲述Java编程中最重要的技能Debug。无论是J2SE，J2EE，J2ME甚至任何其它的编程语言都离不开Debug的使用。课程不会简单地讲述Debug的基本概念，而是通过各种复杂的应用案例，大量的代码分析，以及讲师自身的经验，给学员充分地展现Debug的各种技能，以及工具的应用。

本课程还会介绍JPDA(Java Platform Debug Architecture)的一些基本概念，介绍如何使用JPDA快速建立Java Debug环境。

最后课程会介绍如何使用JPDA调试J2EE程序，以及如何调试多线程程序。

通过本课程，学员可以深刻理解Java编程中各种Debug技巧的应用，以及Debug过程中碰到的各种问题。同时课程围绕着实际案例展开，这样学员可以对Java编程Debug技巧有非常切实的认识。

讲座安排：

Java Debug的基本应用

如何设置断点
如何查看局部变量，如何查看全局变量
如何单步执行，如何调入执行
如何跳出执行

Java Debug的基本应用模式

确定输入，预估输出
单步执行，粗判问题
调入执行，分析结构
跳出执行，忽略细节
发现问题，返查堆栈

Java Debug的高级应用

对象行为与预判不一致
分析输出或者发现问题快速预判
快速定位Exception
快速分析特定情况
调用拦截
提高复杂多断点情况下的效率

JPDA基本概念

JPDA基本概念
Java命令行的JPDA参数意义
使用JPDA快速建立Debug环境

J2EE调试

使用JPDA调试J2EE程序
各种应用服务器的JPDA设置
Web应用程序的调试步骤
EJB应用的调试步骤
J2EE程序调试的各种常用内审对象
J2EE程序线程堆栈的应用

多线程程序调试

使用No suspend调试多线程
使用Log on console和Access log调试多线程

讲座资料：

《Java编程Debug技巧》讲座视频

下载

讲座须知：

主讲：谢峰
在线讲座时间：2009-01-03（原计划2008-12-26 ，因故推迟），晚上 7：00-9：00
报名方式：请在讲座前首先通过网上报名>>>
交流地点：MSN群：uml@uml.com.cn，请在讲座前加入群组。您可以先通过技术论坛说明感兴趣的议题和问题！如有疑问请致电：（010）62670862

主讲简介：

谢峰，系统架构师，上海交通大学硕士。

有多年的J2EE开发和架构设计经验。从事过大型物流软件的架构设计，企业基础平台的设计和开发。目前主要工作是设计基于银行金融业务的企业级架构，和Business Intelligence的应用。
主要特长：面向对象设计与分析，设计模式, UML, J2EE各种技术的综合应用，
分布式计算模型，Richclient Internet Architecture(RIA)架构设计，Web2.0架构设计,
企业级架构整合,商业智能。
著作：《分布式模型改进方案》《基于智能客户端的企业基础平台的设计》

交流实录：

主持人说: 通过线的方式交流关于《Java编程Debug技巧》的一些经验，，并对先前发布的视频<< Java编程Debug技巧>>进行答疑，答疑范围包括但不限于本视频，参与讨论者可以提出自己“Java编程Debug技巧”中的相关问题。本次交流适用于一切对“Java编程Debug技巧”感兴趣的软件行业从业者。
主持人说: 欢迎参加
主持人说: 举下手
若尘说: here
若尘说: 呵呵，估计放假大家还都在外玩呢
主持人说: 是阿
Brandon Xu（徐财）说: 我参加
Brandon Xu（徐财）说: 怎么加入啊
主持人说: 这里就可以了
Brandon Xu（徐财）说: 就在这个群里讲吗?记得以前都是在一个网址里的啊
主持人说: 这里
主持人说: 这里方便些
主持人说: java调试方面，有什么问题，现可以准备一下
主持人说: 视频看否了
主持人说: http://www.uml.org.cn/MyProcess/GuideView/java1127.asp
主持人说: 谢老师来了么
主持人说: 谢老师现已经网络上了
主持人说: 网络有点延时
主持人说: 马上开始
Rainbow! 说: 大家好
主持人说: 谢老师
主持人说: 今天因为元旦节日
主持人说: 人少
主持人说: 我们现开始
主持人说: 这次交流的内容是 java调试技术
Rainbow! 说: 看到了
Rainbow! 说: 终于可以用了
Brandon Xu（徐财）说: 嗯
主持人说: 呵呵
主持人说: 不容易啊
Rainbow! 说: 开始吧，不好意思
主持人说: 今天的主讲是谢峰，系统架构师，上海交通大学硕士。
有多年的J2EE开发和架构设计经验。从事过大型物流软件的架构设计，企业基础平台的设计和开发。目前主要工作是设计基于银行金融业务的企业级架构，和Business Intelligence的应用。
主要特长：面向对象设计与分析，设计模式, UML, J2EE各种技术的综合应用，
分布式计算模型，Richclient Internet Architecture(RIA)架构设计，Web2.0架构设计,
企业级架构整合,商业智能。
著作：《分布式模型改进方案》《基于智能客户端的企业基础平台的设计》
主持人说: 刚才网络延误了一点
主持人说: 现开始
Rainbow! 说: 好
Rainbow! 说: 有啥问题，大家一起share一下
主持人说: 交流的步骤：首先提问，然后按照顺序回答问题，对问题再讨论中深入交流
主持人说: 现大家可以提提自己调试程序方面的问题
Rainbow! 说: 同事们，提问阿，别客气
主持人说: 我有个问题：调试一般是运行时的程序跟踪，谢老师能否谈谈调试和单元测试的联系和差别
Rainbow! 说: 恩
Rainbow! 说: 有相似的地方，也有不同的地方
Rainbow! 说: 相似的地方，就是，无论你是单元调试，还是debug，都需要有一个期望结果
Rainbow! 说: 也就是我们所谓的expect result
主持人说: 哦
Rainbow! 说: 单元调试的时候，可以使用assert来判断expect result
主持人说: 不过我倒是觉得对开发人员，调试更有意义吧
Brandon Xu（徐财）说: 谢老师, 我觉得debug无非就是设置断点, 单步或过程跟踪啊, 应该就是找错啊; 最终解决错误, 怎么能知道expect result呢, 难道这个expect result是自己猜的吗?
Rainbow! 说: 不过在debug，就没这么幸运了，这个期望值必须有一个预判，而且必须开发人员来记住
Rainbow! 说: 这个就需要靠经验，和项目的积累
Rainbow! 说: 这个问题问的好
若尘说: 因为系统中调用其它dll提供的方法，所以有时跳出的异常没有指定位置，只是说明错误的原因，比如没有实例化对象，对于这种错误，怎么定位比较快呢？
Brandon Xu（徐财）说: 看来是因人而异, 因经验的多少而异啊
Rainbow! 说: 对于debug来说，找错无非两种
Rainbow! 说: 一种看到了exception，这种属于非常明显的错误
Brandon Xu（徐财）说: 对呀,对于那种无法通过源代码来debug的错误, 来怎样debug呢, 如dll中的错误等
Rainbow! 说: 对于这种错误，很容易确定是什么cause造成了这种exception，然后找错的过程中，就需要跟踪这种cause的上下文，也就是根据你判断的造成exception得cause，来调试程序，对于每一个函数调入，和调出，都是有一定目的性的，也就是有一个expect result，通过except result来确定最后的根源，以此来修改程序
Rainbow! 说: 对于这种错误，一般只能通过看log来判断
Rainbow! 说: 还有一种，方式，就比较复杂了
Brandon Xu（徐财）说: 哦, 看来无论什么错误, 都是通过像junit中的assert(断言)来判断和expect result是否一样, 是这样吗? 老师
Rainbow! 说: 因为在java程序中，没法对jni的dll进行调试
Rainbow! 说: 只有一个办法，就是靠经验猜，看日志，然后通过add watch来不停的改变输入参数
主持人说: assert(断言)应该是单花园测试的方式，调试更多是原有程序的跟踪吧
Rainbow! 说: 这样可能会提高一点效率，当然最好能找到错误根源不是dll本身
主持人说: 调试是否主要于跟踪代码，
Rainbow! 说: 是的，assert只能是粗略的看某一个大功能
Rainbow! 说: 是否满足要求，当assert发现了错误
主持人说: 对于dll这种无法跟踪的部分，只能借助于dll自我准确的exception体系了
Rainbow! 说: 还是需要通过debug来跟踪的
Rainbow! 说: 对，这种我建议可以使用
Rainbow! 说: 单元测试
Brandon Xu（徐财）说: dll自我准确的exception体系是什么啊, 不太明白, 请老师指点
Rainbow! 说: 呵呵，不是这个意思，主持人的意思就是说任何系统，不管你是dll也好，还是java程序也好，都有一套exception处理机制
Brandon Xu（徐财）说: 哦
主持人说: 呵呵，是阿
Rainbow! 说: 好的机制，或这种准确的机制，能够通过日志或者抛出exception的信息能发现程序的内部错误
Rainbow! 说: 而不是通过debug
Brandon Xu（徐财）说: 我觉得所有的语言类的debug应该都一样, 没什么区别.
主持人说: 系统级别的异常一般都是会引起程序崩溃或者系统级别运算错误，调度
Rainbow! 说: 恩，原则基本都接近
Rainbow! 说: 对的
主持人说: debug的时候对环境需要哪些注意
Rainbow! 说: 不同的地方在于，debug环境的设置
Rainbow! 说: 和利用
Rainbow! 说: 比如
Rainbow! 说: java的jpda就是一个功能很强的平台
Rainbow! 说: 任何java程序debug的基础就是jpda
Rainbow! 说: 所以任何java程序都可以调试
Rainbow! 说: 我遇到很多初级程序员都和我说，j2ee程序，web程序没法调试
Rainbow! 说: 这个只是他们没有掌握特定应用服务器的jpda的设置，可以去看一下说明，一般所有的应用程序都会开放jpda
主持人说: 谢老师能否说一下调试的基本原则
Rainbow! 说: 调试基本原则，我在ppt当中提到了
Rainbow! 说: 我在总结一下
Rainbow! 说: 其实debug调使目的就一句话
Rainbow! 说: 定位问题
Rainbow! 说: 如何修订问题，不是debug的范畴
Rainbow! 说: 定位问题，分这么几个步骤
Rainbow! 说: 首先是，发现错误，也就是最终的错误
Rainbow! 说: 然后根据错误出现点的上下文数据
Rainbow! 说: 来开始调试，错误出现前面的代码
Rainbow! 说: 看是哪一步设置了错误发生点的上下文数据
Rainbow! 说: 这个过程有时候可能，调试一两部，就出来了
Rainbow! 说: 有时候可能就比较复杂
Rainbow! 说: 因为java程序都是基于method
Rainbow! 说: 每一个method都有很多method组成
Rainbow! 说: 这样就造成了，一个程序有大量的method堆栈
Rainbow! 说: 很有可能是某一个堆栈造成
Rainbow! 说: 这时候，就可能一下子无法定位问题
Rainbow! 说: 那就要靠另外几个原则，跳跃执行，忽略细节
tiedollars@hotmail.com 说: 这些堆栈在物理上是嵌套的么？
Rainbow! 说: 可以大跨度的选择几个断点
Rainbow! 说: 然后逐步缩小跨度，最终定位问题
Rainbow! 说: 堆栈理论上是没有嵌套
Rainbow! 说: 一般都是A->B->C，然后退出
Rainbow! 说: 再是另外一个堆栈
Terry 说: 我想问个怪问题 jpda为什么不支持单步后退啊，java调试可以实现单步后退吗
Rainbow! 说: 当然不行，没有回退这一说，只有返回上一个堆栈
Terry 说: 但有些语言可以，用堆栈保护现场啊
tiedollars@hotmail.com 说: 我觉得嵌套单步调试倒不是很难实现，倒是多任务或者说多进程（有IPC的）比较麻烦
Rainbow! 说: 这个没错
Rainbow! 说: 能否说明一下，nested调试，我们可能理解有一点差别
Rainbow! 说: 对于多线成应用程序的调试
Rainbow! 说: 肯定要比一般性的程序复杂不少
Rainbow! 说: 考虑问题也多，设置断电也困难
tiedollars@hotmail.com 说: 随机性太大
Rainbow! 说: 对的
Rainbow! 说: 所以，我在ppt提到采用print on console这种方式
tiedollars@hotmail.com 说: ppt在哪里
Rainbow! 说: 在不破怀运行环境的前提下
Rainbow! 说: 设置print on console德断点
tiedollars@hotmail.com 说: console
Rainbow! 说: 这种breakpoint功能很强
Rainbow! 说: 有点类是外挂的System.out.println
tiedollars@hotmail.com 说: 的断点不影响运行环境的，但做不到每次仿真一样
Rainbow! 说: 而且可以带条件判断
Rainbow! 说: 基本一致巴，print on console肯定有一点开销，不过大部分情况下这个开销可以忽略不计
主持人说: 调试出现的错误
主持人说: 错误发现的方法大概有哪些?
tiedollars@hotmail.com 说: 断点最好是能把系统整个环境停下来
tiedollars@hotmail.com 说: 你这样做系统还在跑，所有任务也都在跑，和另外做一个任务接受log一样，和我们平时用断点的意义不太一样
Rainbow! 说: 这个，不见得，我个人认为调试多线程程序，最好先不要破坏系统的运行，通过print on console的方式大概确定问题，然后再用condition experession结合break point来调试
tiedollars@hotmail.com 说: 你说的是我们现在用的最多的方式
tiedollars@hotmail.com 说: 但我觉得如果我们能够得到停下整个系统所有任务的断点，我会选择用这个
Rainbow! 说: 呵呵，那还有什么高招吗？我想了半天，也就这招了
Rainbow! 说: 你的意思停止所有的线程的task
Rainbow! 说: ？
tiedollars@hotmail.com 说: 恩
tiedollars@hotmail.com 说: 当某一个人物里面的断点被触发，这骨骼系统停下来保存现场
tiedollars@hotmail.com 说: 整个
Rainbow! 说: 这个。。。好像比较难，至少我在现有的ide里面没发现
主持人说: 那如果是步进调试呢
主持人说: 而不是一个断点的监视呢
tiedollars@hotmail.com 说: 是的，没有，只是期望
主持人说: 这个我觉得可能没有实际意义
Rainbow! 说: 我的做法，只是可以将所有的task里面的上下文，打印出来，但是没法让系统hold住
主持人说: 因为多个任务的执行本来就是不可控制的
主持人说: cpu的环境不再控制范围之内
Rainbow! 说: 不过好像我有同事给我讲过intellj 8.0有这么一个功能
主持人说: 那个是并行编程吧
Rainbow! 说: 我还没去认证过
tiedollars@hotmail.com 说: 由于其随机性高，根据log的打印有时候也很难让我们重现故障
主持人说: intel的多核计算
Rainbow! 说: 不是重现
Rainbow! 说: 而只是说放映上下文的数据
主持人说: 能否为调试定个使用的范围
主持人说: 把调试和测试分开
tiedollars@hotmail.com 说: 有时候故障就是几个任务凑巧了出现的，重现不了，没法解决，有时候就不敢发布程序
主持人说: 这两者之间边界有的时候不是很清楚
Rainbow! 说: 测试，我个人认为阿，现在有很多概念，比如测试先行
Rainbow! 说: 单元测试
Rainbow! 说: 等等
Rainbow! 说: 测试相对于调试来说，怎么说呢，应该属于高阶的应用
主持人说: 写程序的时候，单元测试粗略定个问题，然后调试
Rainbow! 说: 或者说，测试只关心我某一个程序，某一个功能
Rainbow! 说: 是不是满足我期望的要求
主持人说: 我就简单写了一个调试框架，这样就可以测试调试一起来
主持人说: 如何
Rainbow! 说: 如果不满足，如何解决这个问题，就是debug的作用了
主持人说: 测试出问题了，需要调试，
Rainbow! 说: 对的
若尘说: who
主持人说: 是否可以把测试作为调试的入口
主持人说: 发现问题主要还是看调试
tiedollars@hotmail.com 说: 发现问题属于测试，定位问题应该属于调试
主持人说: 测试更于发生问题
Rainbow! 说: 可以这么说，好的程序应该先测试，就是划定测试基线
主持人说: 对，我说错了
Rainbow! 说: 然后如何发现根源，解决问题就要靠Debug
tiedollars@hotmail.com 说: 发现根源算哪个？
Rainbow! 说: Debug
tiedollars@hotmail.com 说: 同意
Rainbow! 说: 我说的根源，意思是造成了最终错误的根源，或者是这个根源使你的程序没有达到预期的效果
tiedollars@hotmail.com 说: 是的
主持人说: 错误怎么定义呢，
主持人说: 随机的发现么
主持人说: 不太可靠
Rainbow! 说: 错误？
主持人说: 恩
Rainbow! 说: 我觉得分两种
Rainbow! 说: 一种就是显式的exception
主持人说: 只是当发生严重的故障，然后才调试，问题是有些场景不易捕获
Rainbow! 说: 还有一种就是逻辑错误
Rainbow! 说: 这种错误不是说我有明显的exception发生
主持人说: 是阿
主持人说: exception 倒是容易了
Rainbow! 说: 而是没有达到你期望的结果
Rainbow! 说: 使得，显示的exception好解决
tiedollars@hotmail.com 说: 就像无法完整测试非离散输入一样，只能依靠某些抽样方法来发现问题
主持人说: exception也有相对性
主持人说: 那是否意味着要定义一个完善的exception树
Rainbow! 说: 那这个时候，就需要对程序结构有清晰地了解，然后在你认为没有达到期望结果的出口，进行调试
Rainbow! 说: 或者说就是抓住一个线索的线头吧，从某一个点出发，开始确定整个错误发生的过程
主持人说: 如果把调试和单元测试结合，有什么办法和工具么
Rainbow! 说: 一班我是先测试，发现问题在调试，怎么说呢这两者只能说相辅相成
Rainbow! 说: 结合的话，我很难相处一个办法说，我发现一个test case在某一步不过了，立刻就能确定条试点
主持人说: 我的意思是可以很快转入调试，
tiedollars@hotmail.com 说: 主持的意思我理解是不是在测试过程中，发现一些预期错误能够自动进入断点和调试模式？
主持人说: 恩
Rainbow! 说: 一般的办法，就是，发现断言失败，然后呢就确定断言取值着一个点的上下文环境
tiedollars@hotmail.com 说: 断言在测试中无效吧
Rainbow! 说: 然后结合ide工具，查找是哪一个点改变了这个取值的上下文，在每一个点都可以打上一个break point，这样的话，可以在不知道程序结构的情况下，快速找到调试的切入点
Rainbow! 说: 恩
tiedollars@hotmail.com 说: java开发环境对bp有数量限制么？
Rainbow! 说: 至少我到现在还没发现过
tiedollars@hotmail.com 说: 我们在嵌入式开发中硬bp是很少很少的
Rainbow! 说: 呵呵，应用不通巴
Rainbow! 说: 不同
tiedollars@hotmail.com 说: 恩
主持人说: 大家还有什么问题么
若尘说: 单个方法经过单元测试没有任何问题，整个系统跑起来时出现问题，可以确定是在该方法上，这种情况该怎么处理呢？
heng 说: 问得好！我也正想问呢！
Rainbow! 说: 恩
Rainbow! 说: 这个问题，第一步，肯定是要先确定，你这个问题到底是属于那种类型
Rainbow! 说: 比如显示的exception，还是逻辑错误，比如某些数值没有满足你的期望值
Rainbow! 说: 显示错误好办，直接将断点打在exception的地方
Rainbow! 说: 然后按照我前面说的步骤，一步一步确定问题根源
若尘说: 问题好像就处在DataTable的Select方法上
若尘说: 有时成功，有时失败
Rainbow! 说: 对于后一个问题，就是逻辑错误，比较复杂，但是一个程序无论你有什么错，肯定可以确定由一个点发起的
Rainbow! 说: 可以在这一个点上加断点
Rainbow! 说: 然后在分布划块，确定问题根源
Rainbow! 说: 这个朋友，能否把问题说具体一点
Rainbow! 说: 我可以再补充说明一下测试，如果有你刚刚那个问题
Rainbow! 说: 你可以使用断电
Rainbow! 说: 纪录下来，调入你测试的那个方法，时候的值
Rainbow! 说: 然后改变你的test case
Rainbow! 说: 然后通过test case来缩小，你debug的范围
若尘说: 我需要到DataTable中搜索满足条件的记录，使用的是其Select方法，程序出问题，总是搜索不出对应记录，对指定方法进行单元测试，好像是空格的问题
若尘说: 改正后，对各种特殊情况都进行了测试，通过
若尘说: 过了一段时间，又出现搜不到指定记录的情况
若尘说: 所以觉得这个问题并没有解决
主持人说: 呵呵
若尘说: 但是为什么有时出现，有时不出现现在还不能确定
Rainbow! 说: 是不是数据库的Data Table阿
若尘说: 嗯
Rainbow! 说: 这种就是你测试的策略需要调整
Rainbow! 说: 一般你做涉及数据库单元测试的时候，不能依赖于运行时的数据库，或者说运行时的数据
Rainbow! 说: 而应该独立准备一套数据，来做此类的单元测试
Rainbow! 说: 在java中，有一个叫DBUnit的工具
Rainbow! 说: 就是用来干这个的
Rainbow! 说: 这类数据就是为了证明你某一个方法中的逻辑是否正确
若尘说: 哦
Rainbow! 说: 可以说是一套非常干净的数据，专门用来测试
Rainbow! 说: 如果在使用过程中，发现了问题，就像你说的
Rainbow! 说: 我测试用例好好的
Rainbow! 说: 不过运行时候出问题了
若尘说: 但是如果我测试使用的数据并不是运行中变化的，而是固定的数据，为什么会出现那种时好时坏的毛病呢？
Rainbow! 说: 这时候，debug就派上涌出了
主持人说: 若尘的问题是 ADO.Net 的datatable吧
若尘说: 嗯
Rainbow! 说: 可以通过debug，记录当前的环境，然后再改变dbunit中的测试数据
Rainbow! 说: 我觉得阿，凭我的感觉阿
Rainbow! 说: 你这种情况是出在你的逻辑依赖很多基础数据
Rainbow! 说: 或者很多运行时的数据
Rainbow! 说: 这个时候，就像我说的，首先一定要保证你的db测试数据是正确的
Rainbow! 说: 然后保证你的方法逻辑是正确的
若尘说: 你是说可能我在运行中用于搜索的数据并不是我认为的那些？
Rainbow! 说: 如果再发现问题，那就要看你运行时的数据配置了
主持人说: datatable有缓存机制
主持人说: 也有可能是这个出问题了
Rainbow! 说: 恩，或者说并不是你test case中用的数据
若尘说: 那该怎样避免这类问题呢？
Rainbow! 说: 按照我刚刚说的3步走吧
若尘说: 哦
Rainbow! 说: 有时候我们发现问题了
若尘说: 谢谢，呵呵
Rainbow! 说: 会没头绪
Rainbow! 说: 不知如何解决
Rainbow! 说: debug也是这个样子
Rainbow! 说: 有经验的程序员和没经验的程序员最显著的差别就在这里，发现问题如何抓住头绪来解决
Rainbow! 说: 我给的建议就是，逐步验证你的程序的正确性
主持人说: 这个问题是datatable的具体问题
主持人说: 若尘可以看看如何牵制加载数据
主持人说: 调试只是发现问题了
Rainbow! 说: 比如刚刚你说的问题，就是这样，可变因子太多，你根本没法确定，是你代码的问题，还是数据的问题
主持人说: 解决问题还要看问题本身了
若尘说: 哦
主持人说: http://forums.microsoft.com/china/showpost.aspx?postid=2671610&siteid=15
若尘说: 那调用系统类的方法，是不是我得到想要的结果就算是正确使用了？
若尘说: 比如前面说的，出现故障是因为空格问题
Rainbow! 说: 恩，这个问题比较泛，我不觉得，说调用系统类的方法，有期望结果输出就算正确的
Rainbow! 说: 但是也不能说不正确，要看你的期望结果的定位，比如你说掉一个System.out.println("AAA")
Rainbow! 说: 输出了AAA就是你期望的结果
若尘说: 但是之前没有使用空格的时候，也正常运行了一段时间，只是后面突然跳出问题了，而我使用了空格后，问题暂时解决了
Rainbow! 说: 那这个可以说正确的
Rainbow! 说: 恩，我的意思是还是要看应用
Rainbow! 说: 应用决定了你的期望结果
Rainbow! 说: 我接着补充刚刚的例子
主持人说: 系统类也有运行时的问题
Rainbow! 说: 比如说，由于你的输入参数不正确，或者不合适
Rainbow! 说: 虽然得到了期望的结果
Rainbow! 说: 但是造成了系统的急剧下降
主持人说: dataset，datatable都是内存数据库，会有缓存，并发问题，
Rainbow! 说: 性能的下降
主持人说: 本身设计就可能有问题
Rainbow! 说: 对，还有此类兵法问题
Rainbow! 说: 并发
Rainbow! 说: 那么就是你的设计可能有缺陷
Rainbow! 说: 或者你使用的系统方法不合理
Rainbow! 说: 这个应该也算bug
Rainbow! 说: 而且是很难发现的那种
主持人说: 建议查询少用，直接用command
主持人说: 然后把数据结果返回到datatable就可以了
主持人说: 呵呵
主持人说: 有点题了
主持人说: 调试大家还有什么问题么
Rainbow! 说: 呵呵
主持人说: 我还有个问题，为了利于调试，需要如何编写程序，具有可调试性，例如 try catch的粒度
若尘说: 对对对，以前想问的来着，今天反倒给忘记了
Rainbow! 说: 瓦，这个问题，问得不错
Rainbow! 说: 首先我想说明一点
Rainbow! 说: 调试技巧，不同于设计技巧
Rainbow! 说: 如果真的设计得非常好的程序，基本不需要怎么调试，或者说调试所需要掌握的功力不需要很多
Rainbow! 说: 但是对于设计得不好的程序，那就只好看你的调试功力里，比如让你去一家新公司，第一天就让你改他们老的产品的bug，这种事我向大家都有过经历
Rainbow! 说: 如果从设计角度来讲
Rainbow! 说: 这个话题可能有点跑题，不过我愿意分享一下
Rainbow! 说: 设计角度来讲
Rainbow! 说: 首先你要确定你的实体对象，所谓实体对象就是对一个需求的面向对象化
Rainbow! 说: 比如让你做一个，图书馆管理系统
Rainbow! 说: 这个需求可能大家都知道
Rainbow! 说: 所谓实体对象，其实，简单一点就是对这些需求的名词的抽象，比如，管理员，用户，角色，图书，图书类别，借书记如
Rainbow! 说: 等等
Rainbow! 说: 清晰的设计，就实现对这些实体对象构建模型
Rainbow! 说: 这些实体对象不应该包含任何的逻辑
主持人说: 恩，设计角度，粒度合理的话，有利于问题的分解
Rainbow! 说: 只是一个数据载体
Rainbow! 说: 然后，再是
Rainbow! 说: 业务过程的抽象
Rainbow! 说: 也称为业务对象
Rainbow! 说: 业务对象不应该保存状态
Rainbow! 说: 只是处理一个业务过程
Rainbow! 说: 谈到debug，对于无状态的对象的方法调用，我不需要关心类成员变量
Rainbow! 说: 也就是全局变量，而只需要关心方法堆占
Rainbow! 说: 这样的话就缩小了上下文的可变范围
Rainbow! 说: 业务对象可以使用实体对象
Rainbow! 说: 包括输入和输出
Rainbow! 说: 这样上下文就可以集中在这些实体对象和方法体内的局部变量
主持人说: 嗯
Rainbow! 说: 大大减少了，可变环境
主持人说: 恩
主持人说: 呵呵
Rainbow! 说: 而且对于调试的重点也都放在了业务对象上，而不需要关心实体对象
Rainbow! 说: 这可能就是我想到的便于调试的程序上把
Rainbow! 说: 对于try...catch主持人是否还记得上次公开讲座中的一个责任链模式
Rainbow! 说: 一句话总结这个模式，就是在你范围内的exception一定要管住
Rainbow! 说: 或者说包装起来
主持人说: 哦，记得
Rainbow! 说: 你能处理的exception，就不要抛，处理不了的，就包起来跑
Rainbow! 说: 抛
主持人说: 恩
Rainbow! 说: 我觉得，不知道能否覆盖这个try...catch的力度
主持人说: 可以这么看
主持人说: 还有就是要写多少层次的catch
Rainbow! 说: 恩
主持人说: 如果程序存分层调用
Rainbow! 说: 补充说明可调适程序
Rainbow! 说: 尽量减少引用设值这种程序
Rainbow! 说: 比如我有一个对象A
Rainbow! 说: 有一个方法叫importProperties(A a)
Rainbow! 说: 调用晚了这个方法A就有值了
Rainbow! 说: 这种属于隐式设值
主持人说: 恩
主持人说: 的
主持人说: 理解了
Rainbow! 说: 调试的时候会造成不少麻烦
Rainbow! 说: 还有就是，尽量使用单出口程序
Rainbow! 说: 就是保证一个方法内只有一个return
Rainbow! 说: 减少不必要的return
主持人说: 恩，程序的路径
主持人说: 没错
Rainbow! 说: 还有循环内尽量减少，不必要的break
Rainbow! 说: 尽量用标志位，或者条件，来判断是否要跳出循环
Rainbow! 说: 而不是采用大量的if + break
Rainbow! 说: 这样破坏了程序的结构，而且增加了debug的难度
Rainbow! 说: 我觉得就这些了
主持人说: 的
主持人说: 这个其实可以写一个文章
主持人说: 可调试的设计
主持人说: 呵呵
Rainbow! 说: 呵呵，是啊
主持人说: ，今天时间都过了
主持人说: 就到这里了
Rainbow! 说: 好
主持人说: 谢谢：谢老师
主持人说: 还有各位参加者
Rainbow! 说: 不客气，希望下次再讨论
若尘说: 谢谢谢老师，谢谢主持人，呵呵
主持人说: 呵呵，节日还来这里，不容易，
Rainbow! 说: 呵呵，是啊
主持人说: 明天交流记录会发布出来，如果大家希望了解 java程序调试的细节，还是去看视频
Rainbow! 说: 那我先撤退啦
主持人说: http://www.uml.org.cn/MyProcess/GuideView/java1127.asp
主持人说: 的
主持人说: 88，我也撤了
若尘说: 88,晚安，今天腊八，大家别忘记了吃腊八粥
heng 说: 谢谢！886