异常的定义

在《java编程思想》中这样定义 异常：阻止当前方法或作用域继续执行的问题。虽然java中有异常处理机制，但是要明确一点，决不应该用"正常"的态度来看待异常。绝对一点说异常就是某种意义上的错误，就是问题，它可能会导致程序失败。之所以java要提出异常处理机制，就是要告诉开发人员，你的程序出现了不正常的情况，请注意。异常是程序处理意外情况的机制，当程序发生意外时，我们需要尽可能多的得到意外的信息，包括发生的位置，描述，原因等等。

但是在项目中往往要把异常处理好并非易事，异常的本意是好的，让我们试图修复程序，但是如果事先没有约定或者开发人员没有对异常有深刻的理解。往往会使项目变得越来约糟糕！甚至会造成无法挽回的错误。比如清理工作对于我们来说是必不可少的，因为如果一些消耗资源的操作，比如IO,JDBC。如果我们用完以后没有及时正确的关闭，那后果会很严重，这意味着内存泄露等。这里总结了一些异常处理机制的常见约定，希望对异常有更加深入的理解，以避免在今后的项目中尽量少采坑。

附Java异常类层次结构图

在项目中的一些对异常处理的相关约定或准则

1、不要捕获 Java 类库中定义的继承自 RuntimeException 的运行时异常类，如：IndexOutOfBoundsException / NullPointerException，这类异常由程序员预检查

违法来规避，保证程序健壮性。

正例： 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、在代码中使用“抛异常”还是“返回错误码”，对于公司外的 http/api 开放接口必须使用“错误码”； 而应用内部推荐异常抛出； 跨应用间 RPC 调用优先考虑使用 Result 方式，封装 isSuccess、 “错误码”、 “错误简短信息”。

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

12、对于运行时异常，我们不要用try...catch来捕获处理，而是在程序开发调试阶段，尽量去避免这种异常，一旦发现该异常，正确的做法就会改进程序设计的代码和实现方式，修改程序中的错误，从而避免这种异常。捕获并处理运行时异常是好的解决办法，因为可以通过改进代码实现来避免该种异常的发生。对于受检查异常，没说的，老老实实去按照异常处理的方法去处理，要么用try...catch捕获并解决，要么用throws抛出！对于Error（运行时错误），不需要在程序中做任何处理，出现问题后，应该在程序在外的地方找问题，然后解决。