群组技术交流活动---在线交流: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

最新公开课计划

成功案例
Struts+Spring+Hibernate/EJB+性能优化
华夏基金 ActiveMQ 原理与管理
某民航公司 Java基础编程到应用开发
某风电公司 Java 应用开发平台与迁移
日照港 J2EE应用开发技术框架与实践
某跨国公司 工作流管理JBPM
东方航空公司 高级J2EE及其前沿技术
更多...   
 
 

相关培训课程

Struts+Spring+Hibernate
基于J2EE的Web 2.0应用开发
J2EE设计模式和性能调优
Java EE 5企业级架构设计
Java单元测试方法与技术
Java编程方法与技术

火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
版权所有:UML软件工程组织