02 异常处理
【强制】 Java 类库中定义的可以通过预检查方式规避的
RuntimeException异常不应通过catch的方式来处理,比如:NullPointerException,IndexOutOfBoundsException等。说明
无法通过预检查的异常除外,比如解析字符串形式的数字时,可能存在数字格式错误,不得不通过
catch NumberFormatException来实现。正例
if (obj != null) {...}反例
javatry { obj.method(); } catch (NullPointerException e) { ... }【强制】 异常捕获后不要用来做流程控制或条件控制。
说明
异常设计的初衷是解决程序运行中的意外情况,且异常的处理效率比条件判断方式低。
【强制】
catch时应区分稳定代码和非稳定代码。稳定代码指无论如何不会出错的代码。对于非稳定代码的catch应尽可能区分异常类型,并做对应的异常处理。说明
对大段代码进行
try-catch会导致程序无法根据不同异常正确响应,不利于问题定位,是不负责任的表现。正例
用户注册时,对于非法字符、用户名已存在、密码过于简单等情况,应分别进行判断,并提示给用户。
【强制】 捕获异常是为了处理它,不要捕获了却不处理。如果不想处理异常,应将该异常抛给调用者。最外层的业务使用者必须处理异常,将其转化为用户可以理解的内容。
【强制】 在事务场景中,如果抛出异常并被
catch,需要回滚事务时,一定要注意手动回滚事务。【强制】
finally块必须对资源对象、流对象进行关闭,即使有异常也要进行try-catch。说明
在 JDK 7 中,可以使用
try-with-resources方式。【强制】 不要在
finally块中使用return。说明
try块中的return语句执行成功后,会继续执行finally块中的语句。如果finally中存在return,则会直接返回,忽略try块中的返回点。反例
javaprivate int x = 0; public int checkReturn() { try { // x 等于 1,此处不返回 return ++x; } finally { // 返回的结果是 2 return ++x; } }【强制】 捕获异常与抛异常必须完全匹配,或者捕获异常是抛异常的父类。
说明
- 如果预期对方抛的是绣球,实际接到的是铅球,就会产生意外情况。
- 如果预期抛出的是某种异常,实际却捕获了不同类型的异常,可能会导致意外情况。
【强制】 在调用 RPC、二方包或动态生成类的方法时,捕捉异常应使用
Throwable类进行拦截。说明
通过反射机制来调用方法,如果找不到方法,抛出 NoSuchMethodException。什么情况会抛出 NoSuchMethodError 呢?二方包在类冲突时,仲裁机制可能导致引入非预期的版本使类的方法签名不匹配,或者在字节码修改框架(比如:ASM)动态创建或修改类时,修改了相应的方法签名。这些情况,即使代码编译期是正确的,但在代码运行期时,会抛出 NoSuchMethodError。
反例
足迹服务引入了高版本的 spring,导致运行到某段核心逻辑时,抛出 NoSuchMethodError 错误,catch 用的类却是 Exception,堆栈向上抛,影响到上层业务。这是一个非核心功能点影响到核心应用的典型反例。
【推荐】 方法的返回值可以为
null,不强制返回空集合或空对象等,但必须添加注释,充分说明在何种情况下会返回null。说明
本规约明确防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象,对调用者来说,也并非高枕无忧,必须考虑到远程调用失败,运行时异常等场景返回 null 的情况。
【推荐】 防止 NPE 是程序员的基本修养,注意 NPE 产生的场景:
返回类型为基本数据类型时,如果 return 返回的是包装数据类型对象,自动拆箱可能产生 NPE。
反例
javapublic int method() { // 如果为 null,自动解箱抛 NPE。 return Integer 对象; }数据库查询结果可能为
null。集合里的元素即使
isNotEmpty,取出的数据元素也可能为null。远程调用返回对象时,一律要求进行空指针判断,防止 NPE。
对于 Session 中获取的数据,建议进行 NPE 检查,避免空指针。
级联调用
obj.getA().getB().getC(): 一连串调用,易产生 NPE。
正例
使用 JDK 8 的
Optional类来防止 NPE 问题。【推荐】 定义时应区分
unchecked/checked异常,避免直接抛出new RuntimeException(),更不允许抛出Exception或Throwable,应使用有业务含义的自定义异常。推荐使用已定义过的自定义异常,如:DAOException,ServiceException等。【参考】 对于公司外部的 HTTP/API 开放接口必须使用错误码,而应用内部推荐抛出异常;跨应用间 RPC 调用优先考虑使用
Result方式,封装isSuccess()方法、错误码、错误简短信息;应用内部推荐抛出异常。说明
关于 RPC 方法返回
Result方式的理由:- 使用抛异常返回方式,调用方如果没有捕获到就会产生运行时错误。
- 如果不加栈信息,只是 new 自定义异常,加入自己的理解的 error message,对于调用端解决问题的帮助不会太多。如果加了栈信息,在频繁调用出错的情况下,数据序列化和传输的性能损耗也是问题。