受检异常 非受检异常_java中受检异常尽可能转化为非受检异常

为什么说是"尽可能"的转化呢？昆明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培训的老师提醒大家注意：受检异常威胁到系统的安全性，稳定性、可靠性、正确性时，不能转换为非受检异常。