到底要在哪里处理异常



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

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

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

原则1  throws业务流程异常

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

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

 

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

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

 

由这个原则1可以推理出下面一个原则.

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

注意,这里强调一下是"一般",而不是所有情况.什么情况原则2不适用呢?请看原则3

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

不影响业务流程的异常是指严重级别比较低,只需要记录甚至可以完全忽略的异常.通常不做特别的处理是不想中断正常的业务进程.

 

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