Java是一门面向对象编程语言。

Java编程异常规范

1.Java 类库中定义的一类 RuntimeException 可以通过预先检查进行规避,而不应该 通过catch 来处理,比如:IndexOutOfBoundsException,NullPointerException等等。 

说明:无法通过预检查的异常除外,如在解析一个外部传来的字符串形式数字时,通过 catch NumberFormatException 来实现。

正例:if (obj != null) {...}

反例:try { obj.method() } catch (NullPointerException e) {...}

2.异常不要用来做流程控制,条件控制,因为异常的处理效率比条件分支低。

3.对大段代码进行 try-catch,这是不负责任的表现。catch 时请分清稳定代码和非稳 定代码,稳定代码指的是无论如何不会出错的代码。对于非稳定代码的catch尽可能进行区分 异常类型,再做对应的异常处理。

4.捕获异常是为了处理它,不要捕获了却什么都不处理而抛弃之,如果不想处理它,请将该异常抛给它的调用者。最外层的业务使用者,必须处理异常,将其转化为用户可以理解的内容。

5.有 try 块放到了事务代码中,catch 异常后,如果需要回滚事务,一定要注意手动回滚事务。

6.finally 块必须对资源对象、流对象进行关闭,有异常也要做 try-catch。

说明:如果 JDK7 及以上,可以使用 try-with-resources 方式。

7.不能在 finally 块中使用 return,finally 块中的 return 返回后方法结束执行,不 会再执行 try 块中的 return 语句。

8.捕获异常与抛异常,必须是完全匹配,或者捕获异常是抛异常的父类。

说明:如果预期对方抛的是绣球,实际接到的是铅球,就会产生意外情况。

9.方法的返回值可以为 null,不强制返回空集合,或者空对象等,必须添加注释充分 说明什么情况下会返回 null 值。调用方需要进行 null 判断防止 NPE 问题。

说明:本手册明确防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象,对调用者来说,也并非高枕无忧,必须考虑到远程调用失败、序列化失败、运行时异常等场景返回 null 的情况。  

10.防止 NPE,是程序员的基本修养,注意 NPE 产生的场景:

1)       返回类型为基本数据类型,return 包装数据类型的对象时,自动拆箱有可能产生 NPE。

反例:public int f() { return Integer对象}, 如果为null,自动解箱抛NPE。

2)       数据库的查询结果可能为null。

3)       集合里的元素即使isNotEmpty,取出的数据元素也可能为null。

4)       远程调用返回对象时,一律要求进行空指针判断,防止NPE。

5)       对于Session中获取的数据,建议NPE检查,避免空指针。

6)       级联调用obj.getA().getB().getC();一连串调用,易产生NPE。

正例:使用 JDK8 的 Optional 类来防止 NPE 问题。

11.定义时区分unchecked/checked 异常,避免直接抛出new RuntimeException(), 更不允许抛出 Exception 或者 Throwable,应使用有业务含义的自定义异常。推荐业界已定义过的自定义异常,如:DAOException / ServiceException 等。

12.在代码中使用“抛异常”还是“返回错误码”,对于公司外的 http/api 开放接口必须 使用“错误码”;而应用内部推荐异常抛出;跨应用间 RPC 调用优先考虑使用 Result 方式,封 装 isSuccess()方法、“错误码”、“错误简短信息”。

说明:关于 RPC 方法返回方式使用 Result 方式的理由:

1)       使用抛异常返回方式,调用方如果没有捕获到就会产生运行时错误。

2)       如果不加栈信息,只是new自定义异常,加入自己的理解的error message,对于调用 端解决问题的帮助不会太多。如果加了栈信息,在频繁调用出错的情况下,数据序列化和传输 的性能损耗也是问题。

13.避免出现重复的代码(Don’t Repeat Yourself),即DRY原则。

说明:随意复制和粘贴代码,必然会导致代码的重复,在以后需要修改时,需要修改所有的副本,容易遗漏。必要时抽取共性方法,或者抽象公共类,甚至是组件化。

正例:一个类中有多个public方法,都需要进行数行相同的参数校验操作,这个时候请抽取: private boolean checkParam(DTO dto) {...}

14.分层异常处理规约

在 DAO 层,产生的异常类型有很多,无法用细粒度的异常进行catch,使用catch(Exception e)方式,并throw new DAOException(e),不需要打印日志,因为日志在 Facade/Service 层一定需要捕获并打到日志文件中去,如果同台服务器 再打日志,浪费性能和存储。

在 Service 层出现异常时,必须记录出错日志到磁盘,尽可能带 上参数信息,相当于保护案发现场。

Web 层绝不应该继续往上抛异常,因为已经处于顶层,如果意识到这个异常将导致页面无法正常渲染,那么就应该直接跳转到友好错误页面,加上用户容易理解的错误示信息。开放接口层要将异常处理成错误码 和错误信息方式返回。

15.对于被调用方,应该尽量少返回异常,确保业务流程正常运行。比如获取缓存失败,只需要返回null即可。如果缓存宕机,可以采用探针方式发现。

16.明确需要调用方处理的,必须声明为checked Exception。比如无法打开配置文件,并且默认配置不可用。Checked Exception应当只在异常情况对于API以及API的使用者都无法避免的情况下被使用。一个Checked Exception应该有明确的意义。我们应该最近化地对Checked Exception进行处理。这是因为随着Checked Exception沿着函数调用的轨迹向上传递的过程中,这些被抛出的Checked Exception的意义将逐渐模糊。

17. 尽量少抛异常,如是手机号码不存在,返回null,在返回值中进行说明,然后客户端处理这个逻辑,而不需要返回异常。能用return 返回值处理的,尽量用返回值,返回值复杂或者碰到业务处理复杂的可以抛出异常。

18.方法接口禁止throw exception。

19.大部分情况下不建议在循环中进行异常处理,应该在循环外对异常进行捕获处理。

20. 为你的异常生成足够的文档说明,至少是 JavaDoc。为每个异常消息定义一个数值,这对好的文档来说是非常重要的,常见的做法就是使用枚举类来管理错误码。

当前位置:Java教程网 »
本文地址:http://www.javajcw.com/86.html
喜欢 or
默认图片
发表我的评论
取消评论