来自大厂的11条异常最佳实践

引言

此文的灵感来自于

异常，这个名词对于开发同学来说应该非常不陌生，是在我们程序出现错误或者业务逻辑不通的时候，给予程序一个安全退出的通道

如何优雅的进行异常处理是一门艺术，本文就给大家提一提处理异常的正确姿势（默认阅读本文的小伙伴已经掌握了异常相关的基础知识）

优雅异常处理

线上代码禁止使用 printStackTrace()

printStackTrace()只会在控制台上输出错误的堆栈信息，他只适合于用来代码调试。

真正需要记录异常，请使用日志记录

Java 类库中定义的可以通过预检查方式规避的 RuntimeException 异常不应该通过
catch 的方式来处理

比如:NullPointerException，IndexOutOfBoundsException 等等。

说明:无法通过预检查的异常除外，比如，在解析字符串形式的数字时，可能存在数字格式错误，不得不
通过 catch NumberFormatException 来实现。

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

//反例
try { obj.method(); } catch (NullPointerException e) {...}
复制代码

异常捕获后不要用来做流程控制，条件控制

异常设计的初衷是解决程序运行中的各种意外情况，而不是做 iflese 这样的条件控制，在 catch 里去做业务逻辑，catch 中一般处理异常的抛出，日志的记录，并且异常的处理效率比条件判断方式要低很多

catch时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。 对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理

对大段代码进行 try-catch，使程序无法根据不同的异常做出正确的应激反应，也不利于定位问题，
这是一种不负责任的表现。

就比如我们一个用户提现的逻辑，我们需要抛出异常给程序提示 余额不足不允许穷鬼提现、这是个坏人他输入的密码错误 等等，而不是一股脑的提示 提现失败

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

// 反例
catch (NoSuchMethodException e) {
   return null;
}

// 正例
catch (NoSuchMethodException e) {
   throw new BizException("错误码","错误原因")
}
复制代码

事务场景中，抛出异常被catch后，如果需要回滚，一定要注意手动回滚事务

// 正例
public void test() {
      TransactionDefinition tra = new DefaultTransactionDefinition();
      TransactionStatus status = transactionManager.getTransaction(tra);

       try {
         // 事务操作
         // 事务提交
         transactionManager.commit(status);
      } catch (DataAccessException e) {
         // 事务提交
         transactionManager.rollback(status);
         throw e;
      }
}
复制代码

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

// 通常做法
catch (Exception e) {
		e.printStackTrace(); // 第一处异常处理
	}
	finally {
        try {
            if (c != null) {
                c.close();
            }
        } catch (IOException e) {
            e.printStackTrace(); // 第二处异常处理
        }
    }

// 说明:如果 JDK7 及以上，可以使用 try-with-resources 方式。
public class Main {
    public static void startTest() {
        try (MyAutoCloseA a = new MyAutoCloseA();
             MyAutoCloseB b = new MyAutoCloseB()) {
            a.test();
            b.test();
        } catch (Exception e) {
            System.out.println("Main: exception");
            System.out.println(e.getMessage());
            Throwable[] suppressed = e.getSuppressed();
            for (int i = 0; i < suppressed.length; i++)
                System.out.println(suppressed[i].getMessage());
        }
    }

    public static void main(String[] args) throws Exception {
        startTest();
    }
}

复制代码

不要在 finally 块中使用 return

try 块中的 return 语句执行成功后，并不马上返回，而是继续执行 finally 块中的语句，如果此处存
在 return 语句，则在此直接返回，无情丢弃掉 try 块中的返回点。

    // 反例:
    private int x = 0;
    public int checkReturn() {
        try {
            // x 等于 1，此处不返回
            return ++x;
        } finally {
            // 返回的结果是 2
            return ++x;
        }
    }
复制代码

另外，不要在 finally 块中抛出异常

捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类

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

在调用 RPC、二方包、或动态生成类的相关方法时，捕捉异常必须使用 Throwable
类来进行拦截

通过反射机制来调用方法，如果找不到方法，抛出 NoSuchMethodException。什么情况会抛出
NoSuchMethodError 呢?二方包在类冲突时，仲裁机制可能导致引入非预期的版本使类的方法签名不匹配，
或者在字节码修改框架(比如:ASM)动态创建或修改类时，修改了相应的方法签名。这些情况，即使代
码编译期是正确的，但在代码运行期时，会抛出 NoSuchMethodError

不打算处理异常的话，使用finally块进行处理，而不是catch块

try {
  someMethod(); 
} 
finally
{
  cleanUp();    
}
复制代码

如果在方法中出现了异常，而不想处理，可以在 finally 中直接处理，无需 catch

参考：

阿里巴巴：《Java开发手册》

谨思慎言，我是 Skow

点个赞再走吧，我们下期再见