程序开发中异常的理解及处理异常

时间:2020-10-12 19:38:34 计算机应用毕业论文 我要投稿

程序开发中异常的理解及处理异常

从接触异常开始我就弄不明白她,不会用她,想在系统中是异常机制发挥的淋漓尽致,进行了很多尝试,利用异常控制程序流程,利用异常做数字的判断函数,利用异常消除系统中可能出现的恼人的异常提示框,为了更好了利用异常看了很多关于异常的文章,直到有一天看到了一句话——“永远不要去处理你不知道怎么处理的异常”,这才恍然大悟,感觉自己一直在用强大的异常机制干一些旁门左道的是事,更谈不上理解异常在程序中的地位和意义,异常其实一种报告机制,“她以一种不可回避的方式报告程序中所出现的问题”,她帮助程序员走向正确的道路,她忠实的向程序员提供错误报告,她希望有谁能重视并处理掉她报告的问题,哈,真不敢想象,没有了异常机制该如何编制高质量的程序!下面就个人的理解和看法瞎说几句,敬请各位批评指正,不胜感激!异常的工作原理,在有问题的地方产生异常,马上停止当前的工作,转向异常处理代码,如果找不到异常处理代码,就会见异常向一层汇报,上一层接到异常会做同样的事,转向异常处理代码,或者再将异常向上汇报,这样逐层间错误传递出去,直到有一层处理了异常或是一直报告给程序的使用者——用户。这个层就是调用栈,当用户A运行程序B,B从函数C开始执行,调用函数D,再调用函数E,再调用函数F,这时F出现了异常,那么这个异常的调用栈就是A(栈底)—〉B—〉C—〉D—〉E—〉F(栈顶),这个异常就会沿着这个栈从栈顶开始向栈底的方向报告,如果在函数C中有对这个异常的处理代码,那么这个异常的报告链就是F—〉E—〉D—〉C。可以看出,如果在完整的调用栈中没有处理这个异常的代码,用户A就成了异常报告的终点,向windows界面系统,会弹出一个恼人的消息对话框哈。那么用户A向谁报告呢,哈哈,这个已经不属于程序的范围了,感觉用会对程序而言好像上帝一样,诉说痛苦已经让上帝都听到了,就心满意足了哈哈,看来程序真虔诚哈哈。对于异常这个特性,也可以比喻成下属向上级报告问题,如果下属知情不报,问题就严重了,你要是领导知道下属是这样的八成就踢了他,相反如果你有一个报告机制健全的下属队伍,哈哈你就威风了。日本企业文蛤中有个宗旨——联络,商谈,报告,其实就是想让员工都具有向上级汇报的习惯。现在再看看程序,哈哈,你不用给她们灌输什么企业文化,不用她们讲述什么报告的重要性,她们本身就是忠实报告的,如果把程序员比作企业老总,那么程序就是训练一队有素的员工。怎样处理异常。在这里有个原则就是“永远不要去处理你不知道怎么处理的异常”,也就是只处理你知道如何处理的异常,对那些你不知道的异常必须广开言路,并积极地向上级汇报。什么叫知道如何处理呢?先说一下处理异常有哪些方式,大体有,弹出提示消息框(这个消息框不同于那个恼人的异常报告消息框,她是捕获异常后,根据处理的具体环境程序员主动编写的友好的提示消息框),记录错误日志,吞掉,做善后工作等等,那么出现异常时就要站在出现异常的模块的.立场上考虑一下我应该选择哪种处理方式呢?如果不能做出选择就选择不处理,即向上级报告。举个例子,函数Fun1是创建并返回一个活动的数据连接对象的方法,他接受一个数据库连接字符串,如果调用者(上级)给他一个错误的连接字符串,这时Fun1创建不了连接对象,产生了一个创建不了连接对象的异常,那么这时他应该怎样处理这个异常呢?弹出友好的消息框?说什么友好,Fun1根本就不知道是什么原因使他接收到了错误的连接字符串,弹一个“连接字符串有误”,用户肯定都有杀你的心,这个提示和用户的业务逻辑有嘛关系!记录错误日志,这个还行,但是记录下来的文字无非就是“连接字符串有误,连接字符串是:SQL……”,好点的话,从连接字符串中看出了问题,一般情况下还得根据代码上下文去找问题原因。这个方式不是不行是不好。吞掉,哈哈开什么玩笑,你既创建不了连接,又不吱一声,想让调用者疯了呀,这个肯定不行。做善后工作,行,确实应该清理一下现场,免得浪费资源,但是还是没吱一声,所以这个方式做的不彻底。没招了,哈,其实上面的分析给我们指明了一条路,帮助我们祛除了错误的选择,这条路就是向上汇报,或是不加任何出来代码,或是记录日志,做些善后,再重新将异常抛出。那么什么时候就知道怎样处理异常了,这就得看实际的情况和用户的要求了,这句话等于没说,就像其他的标题醒目但给出的结论却模棱两可文章一样,哈哈,这里可以给几个建议,1,一般地,底层模块或是方法中不要处理异常,2,编写公共模块、DLL等是,不能采用弹出对话框等依赖于平台,框架的方式处理异常,3,编写公共模块、DLL等时,必须在使用文档中注明每个方法属性可能抛出的异常。4,永远不要写 try 这样的语句。{ } catch(Exception) { o nothing } 自定义异常。明白了异常的原理和机制后,就可以自己定义异常了,这样的实践往往在编写控件、公共模块、DLL等的时候,用错误编号在网上搜索一下,能找出一大堆关于错误代码的描述。其中大多数是M(icro)S(oft)制定的,MS 从操作系统到各种各样的框架都有对各种异常的编号,对每种异常做出了详细的定义,如果你还用过像Spread等商业控件,也可以看到他里边的各种各样的异常定义,也就是说我们自己也可以定义异常,在必要的时候,这样就可以让自己写的模块也加入到训练有素的员工队伍中了。至于如何定义异常,具体的编成语言有具体的做法,比如C#中指定一异常一个从Exception继承来的类,VB中异常是个全局变量等等,参见感兴趣语言的语法指南就可以了。对异常的重新认识,一直以来许多人都认为异常是非常可怕的,可恶的,她是错误的化身,她有恼人的弹出对话框,弄得用户跟凶煞恶神似的哈哈,其实这些都是误解,异常一直默默地忠实的报告着程序中出现的严重的不可回避的问题,她为了程序、系统的正确性、严谨性呼唤你,希望你重视这些问题,希望你用智慧解决这些问题,她是多么的可爱,又是多么的高尚,从来没有因为对她的误解而放弃自己的使命……异常很重要,我们更好学会如何去使用她。论文出处(作者):
浅谈对程序开发中异常的理解和认识