1700448844
以User接口为例，我们在声明接口时不再声明异常，而是在具体实现时根据不同的情况产生不同的非受检异常，这样持久层和逻辑层抛出的异常将会由展现层自行决定如何展示，不再受异常的规则约束了，大大简化开发工作，提高了代码的可读性。
1700448845
1700448846
那问题又来了：在开发和设计时什么样的受检异常有必要转化为非受检异常呢？“尽可能”是以什么作为判断依据呢？受检异常转换为非受检异常是需要根据项目的场景来决定的，例如同样是刷卡，员工拿着自己的工卡到考勤机上打考勤，此时如果附近有磁性物质干扰，则考勤机可以把这种受检异常转化为非受检异常，黄灯闪烁后不做任何记录登记，因为考勤失败这种情景不是“致命”的业务逻辑，出错了，重新刷一下即可。但是到银行网点取钱就不一样了，拿着银行卡到银行取钱，同样有磁性物质干扰，刷不出来，那这种异常就必须登记处理，否则会成为威胁银行卡安全的事件。汇总成一句话：当受检异常威胁到了系统的安全性、稳定性、可靠性、正确性时，则必须处理，不能转化为非受检异常，其他情况则可以转换为非受检异常。
1700448847
1700448848
注意 受检异常威胁到系统的安全性、稳定性、可靠性、正确性时，不能转换为非受检异常。
1700448849
1700448850
1700448851
1700448852
1700448854
编写高质量代码：改善Java程序的151个建议 建议113：不要在finally块中处理返回值
1700448855
1700448856
在finally代码块中处理返回值，这是考试和面试中经常出现的题目。虽然可以以此来出考试题，但在项目中绝对不能在finally代码块中出现return语句，这是因为这种处理方式非常容易产生“误解”，会严重误导开发者。例如如下代码：
1700448857
1700448858
public static void main（String[]args）{
1700448859
1700448860
try{
1700448861
1700448862
doStuff（-1）；
1700448863
1700448864
doStuff（100）；
1700448865
1700448866
}catch（Exception e）{
1700448867
1700448868
System.out.println（“这里是永远都不会到达的”）；
1700448869
1700448870
}
1700448871
1700448872
}
1700448873
1700448874
//该方法抛出受检异常
1700448875
1700448876
public static int doStuff（int_p）throws Exception{
1700448877
1700448878
try{
1700448879
1700448880
if（_p＜0）{
1700448881
1700448882
throw new DataFormatException（“数据格式错误”）；
1700448883
1700448884
}else{
1700448885
1700448886
return_p；
1700448887
1700448888
}
1700448889
1700448890
}catch（Exception e）{
1700448891
1700448892
//异常处理
1700448893
[
上一页 ]
[ :1.700448844e+09 ]
[
下一页 ]