到底要在哪里处理异常

通过了一些实践和思考,我开始有点感受了,就在我被别人问到这个问题以后,我这样总结到:
" 判断异常要不要throws,关键看调用者是否关注这个异常;若不关注,则就地catch处理掉"

貌似有点指导意义了, 不过如何指导调用者是否关注呢?若你是少有参与设计,且只负责一小块功能模块的程序,这个问题对于你来讲确实很差判断.由于它的判断是须要基于全局的,一般设计者要慎重考虑.那么设计者是如何把握异常的处理呢,其中的原则又是什么呢?

这里我就本身的理解,总结一下以供参考.

原则1  throws业务流程异常

业务流程异常是指业务流程中预料到的异常而且要对此进行处理. 举个ATM提款的例子来讲明:

ATM提款后,都会有打印一个"回执"给用户.但"回执"的纸张不是每次都够用的(我就常常遇到这种破事),这中异常状况一般都会在用户插卡输入正确的密码以后,出现询问"没法打印回执,是否继续?"的提示. 此时这异常就须要从检查纸张的低层模块中throws给业务逻辑处理模块,再抛给界面处理模块等待用户处理.

 

也许这个例子对于I/O或格式转换类的基础异常可能不能彻底说明问题,那么再看一个文件读取的例子:

有个文件上传的程序,须要用户经过界面输入要上传的文件,此时是有可能出现文件不存在或文件被锁定之类的问题的.所以,访问文件I/O的低层模块就须要把这类异常throws给调用者,同上面的例子同样交给用户处理.

 

由这个原则1能够推理出下面一个原则.

原则2  低层被调用的模块的异常通常都throws给它的调用者处理

注意,这里强调一下是"通常",而不是全部状况.什么状况原则2不适用呢?请看原则3

原则3  catch不影响业务流程的异常

不影响业务流程的异常是指严重级别比较低,只须要记录甚至能够彻底忽略的异常.一般不作特别的处理是不想中断正常的业务进程.

 

此外,还补充一点,对于须要销毁或释放资源的业务逻辑中,异常的处理很须要经验和技巧的,由于处理不当容易形成内存泄漏和低效率的问题,这块我尚无成熟经验.

 

本文转自 http://zhongl.iteye.com/blog/122426