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

程序开发中异常的理解及处理异常 从接触异常开始我就弄不明白她，不会用她，想在系统中是异常机制发挥的淋漓尽致，进行了很多尝试，利用异常控制程序流程，利用异常做数字的判断函数，利用异常消除系统中可能出现的恼人的异常提示框，为了更好了利用异常看了很多关于异常的文章，直到有一天看到了一句话——“永远不要去处理你不知道怎么处理的异常”，这才恍然大悟，感觉自己一直在用强大的异常机制干一些旁门左道的是事，更谈不上理解异常在程序中的地位和意义，异常其实一种报告机制，“她以一种不可回避的方式报告程序中所出现的问题”，她帮助程序员走向正确的道路，她忠实的向程序员提供错误报告，她希望有谁能重视并处理掉她报告的问题，哈，真不敢想象，没有了异常机制该如何编制高质量的程序！下面就个人的理解和看法瞎说几句，敬请各位批评指正，不胜感激！异常的工作原理，在有问题的地方产生异常，马上停止当前的工作，转向异常处理代码，如果找不到异常处理代码，就会见异常向一层汇报，上一层接到异常会做同样的事，转向异常处理代码，或者再将异常向上汇报，这样逐层间错误传递出去，直到有一层处理了异常或是一直报告给程序的使用者——用户。这个层就是调用栈，当用户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 } 自定义异常。明白了异常的原理和机制后，就可以自己定义异常了