到底要在哪里处理异常

大多数java教程的书籍中,对异常的处理都是及时的,也就是哪里抛了,就在哪里catch.

看别人的代码渐渐多了,就有些模糊的意识到不是所有的异常都是及时处理的,而是通过throws抛给调用者处理.

问题出来,每次遇到异常的时候,我就在catch与throws之间挣扎好久,那么到底要在哪里处理异常?似乎书上并没有答案.

我曾就这个问题请教过一个前辈,他的解答是"在合适的地方处理". 汗,我被这有点"玄机"的回答给忽悠了.

经过了一些实践和思考,我开始有点感觉了,就在我被别人问到这个问题之后,我这样总结到:

"判断异常要不要throws,关键看调用者是否关注这个异常;若不关注,则就地catch处理掉"

貌似有点指导意义了:P. 不过如何指导调用者是否关注呢?

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

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

• 原则1  throws业务流程异常,
  

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

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

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

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

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

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

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

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

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

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