永远不要跟别人比幸运,我从来没想过我比别人幸运,我也许比他们更有毅力,在最困难的时候,他们熬不住了,我可以多熬一秒钟、两秒钟,甚至更久。

到底要在哪里处理异常

Java 新民 1672℃ 已收录 1评论
经过了一些实践和思考,我开始有点感觉了,就在我被别人问到这个问题之后,我这样总结到:
判断异常要不要throws,关键看调用者是否关注这个异常;若不关注,则就地catch处理掉
貌似有点指导意义了, 不过如何指导调用者是否关注呢?若你是少有参与设计,且只负责一小块功能模块的程序,这个问题对于你来说确实不好判断.因为它的判断是需要基于全局的,通常设计者要慎重考虑.那么设计者是如何把握异常的处理呢,其中的原则又是什么呢?
这里我就自己的理解,总结一下以供参考.

原则1  throws业务流程异常

业务流程异常是指业务流程中预料到的异常并且要对此进行处理. 举个ATM提款的例子来说明:
ATM提款后,都会有打印一个”回执”给用户.但”回执”的纸张不是每次都够用的(我就经常遇到这种破事),这中异常情况通常都会在用户插卡输入正确的密码之后,出现询问”无法打印回执,是否继续?”的提示. 此时这异常就需要从检查纸张的低层模块中throws给业务逻辑处理模块,再抛给界面处理模块等待用户处理.
也许这个例子对于I/O或格式转换类的基础异常可能不能完全说明问题,那么再看一个文件读取的例子:
有个文件上传的程序,需要用户通过界面输入要上传的文件,此时是有可能出现文件不存在或文件被锁定之类的问题的.因此,访问文件I/O的低层模块就需要把这类异常throws给调用者,同上面的例子一样交给用户处理.
由这个原则1可以推理出下面一个原则.

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

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

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

不影响业务流程的异常是指严重级别比较低,只需要记录甚至可以完全忽略的异常.通常不做特别的处理是不想中断正常的业务进程.
此外,还补充一点,对于需要销毁或释放资源的业务逻辑中,异常的处理很需要经验和技巧的,因为处理不当容易造成内存泄漏和低效率的问题,这块我尚无成熟经验.
本站文章如未注明,均为原创丨本网站采用BY-NC-SA协议进行授权,转载请注明转自:http://www.snowruin.com/?p=147
喜欢 (1)or分享 (0)
发表我的评论
取消评论
表情 代码 贴图 加粗 链接 私信 删除线 签到

Hi,请填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
(1)条精彩评论。
  1. 学习了!!
    全智贤奶贝多2014-08-13 13:58 回复| Google Chrome 21.0.1180.89| Windows XP