课程咨询 :186 8716 1620      qq:2066486918

昆明Java培训 > 达内新闻 > java中受检异常尽可能转化为非受检异常
  • java中受检异常尽可能转化为非受检异常

    发布:昆明Java培训      来源:达内新闻      时间:2016-10-19

  • 为什么说是"尽可能"的转化呢?昆明Java培训的老师知道,因为"把所有的受检异常(Checked Exception)"都转化为非受检异常(Unchecked Exception)"这一想法是不现实的:受检异常是正常逻辑的一种补偿手段,特别是对可靠性要求比较高的系统来说,在某些条件下必须抛出受检异常以便由程序进行补偿处理,也就是说受检异常有合理存在的理由,那为什么要把受检 常转化为非受检异常呢?难道说受检异常有什么缺陷或者不足吗?是的,受检异常确实有不足的地方:

    (1)、受检异常使接口声明脆弱

    OOP(Object Oriented Programming,面向对象程序设计)要求我们尽量多地面向接口编程,可以提高代码的扩展性、稳定性等,但是涉及异常问题就不一样了,例如系统初期是这样设计一个接口的:

    interface User{

    //修改用户密码,抛出安全异常

    public void changePassword() throws MySecurityException;

    }

    随着系统的开发,User接口有了多个实现者,比如普通的用户UserImpl、模拟用户MockUserImpl(用作测试或系统管理)、非实体用户NonUserImpl(如自动执行机,逻辑处理器等),此时如果发现changePassword方法可能还需要抛出RejectChangeException( 绝修改异常,如自动执行正在处理的任务时不能修改其代码),那就需要修改User接口了:changePassword方法增加抛出RejectChangeException异常,这会导致所有的User调用者都要追加了对RejectChangeException异常问题的处理。

    这里产生了两个问题:一、异常是主逻辑的补充逻辑,修改一个补充逻辑,就会导致主逻辑也被修改,也就是出现了实现类"逆影响"接口的情景,我们知道实现类是不稳定的,而接口是稳定的,一旦定义了异常,则增加了接口的 不稳定性,这是面向对象设计的严重亵渎;二、实现的变更最终会影响到调用者,破坏了封装性,这也是迪米特法则所不能容忍的。

    (2)、受检异常使代码的可读性降低

    一个方法增加可受检异常,则必须有一个调用者对异常进行处理,比如无受检异常方法doStuff是这样调用的:

    public static void main(String[] args) {

    doStuff();

    }

    doStuff方法一旦增加受检异常就不一样了,代码如下:

    public static void main(String[] args) {

    try{

    doStuff();

    }catch(Exception e){

    e.printStackTrace();

    }

    }

    doStuff方法增加了throws Exception,调用者就必须至少增加4条语句来处理该异常,代码膨胀许多,可读性也降低了,特别是在多个异常需要捕捉的情况下,多个catch块多个异常处理,而且还可能在catch块中再次抛出异常,这大大降低了代码的可读性。

    (3)、受检异常增加了开发工作量

    昆明Java培训的老师知道,异常需要封装和传递,只有封装才能让异常更容易理解,上层模块才能更好的处理,可这会导致低层级的异常没玩没了的封装,无端加重了开发的工作量。比如FileNotFoundException进行封装,并抛出到上一 层级,于是增加了开发工作量。

    受检异常有这么多的缺点,那有没有什么方法可以避免或减少这些缺点呢?有,很简单的一个规则:将受检异常转化为非受检异常即可,但是我们也不能把所有的受检异常转化为非受检异常,原因是在编码期上层模块不知道下 模块会抛出何种非受检异常,只有通过规则或文档来描述,可以这样说:

    受检异常提出的是"法律下的自由",必须遵守异常的约定才能自由编写代码。

    非受检异常则是“协约性质的自由”,你必须告诉我你要抛什么异常,否则不会处理。

    以User接口为例,我们在声明接口时不再声明异常,而是在具体实现时根据不同的情况产生不同的非受检异常,这样持久层和逻辑层抛出的异常将会由展现自行决定如何展示,不再受异常的规则约束了,大大简化开发工作,提高 代码的可读性。

    那问题又来了,在开发和设计时什么样的受检异常有必要化为非受检异常呢?"尽可能"是以什么作为判断依据呢?受检异常转换为非受检异常是需要根据项目的场景来决定的,例如同样是刷卡,员工拿着自己的工卡到考勤机上打 考勤,此时如果附近有磁性物质干扰,则考勤机可以把这种受检异常转化为非受检异常,黄灯闪烁后不做任何记录登记,因为考勤失败这种情景不是"致命"的业务逻辑,出错了,重新刷一下即可。但是到银行网点取钱就不一样了 拿着银行卡到银行取钱,同样有磁性物质干扰,刷不出来,那这种异常就必须登记处理,否则会成为威胁银行卡安全的事件。汇总成一句话:当受检异常威胁到了系统的安全性,稳定性,可靠性、正确性时,则必须处理,不能 化为非受检异常,其它情况则可以转化为非受检异常。

    昆明Java培训的老师提醒大家注意:受检异常威胁到系统的安全性,稳定性、可靠性、正确性时,不能转换为非受检异常。

    推荐文章

上一篇:java中采用异常链传递异常

下一篇:【昆明Java培训】不要在finally块中处理返回值

最新开班日期  |  更多

Java--零基础全日制班

Java--零基础全日制班

开班日期:11/30

Java--零基础业余班

Java--零基础业余班

开班日期:11/30

Java--周末提升班

Java--周末提升班

开班日期:11/30

Java--零基础周末班

Java--零基础周末班

开班日期:11/30

  • 网址:http://km .java.tedu.cn      地址:昆明市官渡区春城路62号证券大厦附楼6楼
  • 课程培训电话:186 8716 1620      qq:2066486918    全国服务监督电话:400-827-0010
  • 服务邮箱 ts@tedu.cn
  • 2001-2016 达内国际公司(TARENA INTERNATIONAL,INC.) 版权所有 京ICP证08000853号-56