简介

异常是我们日常开发中一定会遇到的问题，如果我们不了解异常的使用及处理方法，那么我们会恐惧遇到异常机制。但是如果我们对异常的机制有了一定的了解，我们可以通过异常方便的发现程序的问题及优雅的处理这些异常，我们甚至可以通过异常机制使得代码更加的整洁，清晰。本篇博客将会简单的对java的异常机制进行介绍。

java异常基础知识

异常也就是不正常，是程序中出现了没有预料到的错误情况，它会干扰程序的正常执行，将程序控制权转移到异常处理器。下面看一个java异常基础知识的备忘单：

如上图所示，Throwable是java所有异常类的父类，Error和Exception是其两个子类。其中Error代表程序发生了严重的错误，这种错误程序是无法处理的，只能终止，如我们常见的OutOfMemoryError，StackOverflowError。而Exception是程序本身可以处理的异常，可以分为RuntimeException 和 Checked Exception。其中RuntimeException 在程序编译器不会对该异常进行检查，是一种UnChecked Exception，常见的RuntimeException有NullPointException，ClassCastException。而Checked Exception是一类异常的统称，Exception的所有非RuntimeException都是Checked Exception，编译器会对这种异常进行检查，要么捕获这种异常进行处理，要么继续抛出，常见的Checked Exceptiony有IOException，ClassNotFoundException等。

上图还给出了线上环境出现频率最高的10种异常，可以看出NPE高居榜首，一个不会判空的程序员不是一个合格的程序员。

java异常机制原理分析

我们知道java通过try...catch...finally语法来处理java异常，实际java编译器会将try...catch...finally编译生成一个异常表（Exception table），异常记录表记录了异常发生的指令范围及异常处理器的指令位置。下面我们通过一个简单的示例来看下异常表，代码如下，就是简单的try...catch...finally语句。

public class ExceptionTest {
    public static void main(String [] args) {
        try {
            throw new Exception();
        } catch (Exception e) {
            //不做任何操作
        } finally {
            //不做任何操作
        }
    }
}

我们将上述代码编译为字节码如下，异常表说明0-8行代码指令发生任何类型是java/lang/Exception的异常（包括其子类），都执行第8行指令（这里因为catch里不做任何操作），0-9行有任何异常都只执行第12行。看到这里也就基本try...catch是如何改变指令的执行流程的了。

public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=3, args_size=1
         0: new           #2                  // class java/lang/Exception
         3: dup
         4: invokespecial #3                  // Method java/lang/Exception."<init>":()V
         7: athrow
         8: astore_1
         9: goto          15
        12: astore_2
        13: aload_2
        14: athrow
        15: return
      Exception table:
         from    to  target type
             0     8     8   Class java/lang/Exception
             0     9    12   any

从上面的代码指令可以看出，异常通过athrow指令抛出，那么如果异常表中没有所抛出异常的处理器，那么会放生什么呢？

分析这个问题，我们就要看下java的栈帧，栈帧是支持支持java虚拟机进行方法调用和执行的数据结构，存储了方法内的局部变量，操作数栈，方法返回地址等信息。栈帧存放在线程的栈里，每个方法的调用过程就是栈帧的入栈和出栈过程，所以栈顶的栈帧对应着当前正在执行的方法。当athrow指定执行并且异常不能被捕获处理，那么当前方法的栈帧出栈，继续由栈顶的栈帧对应的方法处理抛出的异常直到异常被处理。如果一直到线程的栈空都没有处理该异常，那么线程就会被迫退出终止，这是非常可怕的。所以在java异常基础知识的备忘单的异常使用说明了特别列出了：异常必须被处理！

之前组里推崇使用自定义业务异常来控制流程执行，上层调用方法可以通过异常原因获取具体失败的原因。本人一直对这种代码风格持怀疑态度，我们完全可以通过if...else来替代这种方式，那么两种方式哪个更好呢？

从性能上来说使用异常要更耗时，异常对象的新建比普通对象更耗时，需要将堆栈信息都存储一遍，具体可以看下Throwable类的构造方法中都会调如下native方法做这件事情：

public synchronized Throwable fillInStackTrace() {
        if (stackTrace != null ||
            backtrace != null /* Out of protocol state */ ) {
            fillInStackTrace(0);
            stackTrace = UNASSIGNED_STACK;
        }
        return this;
    }
private native Throwable fillInStackTrace(int dummy);

而异常抛出后，处理异常也需要遍历异常表找到异常处理器，对于没有找到对应异常处理器的情况还要继续向上抛出遍历调用方所在类的异常处理器，这也是一个耗时过程。我们以下面的示例对使用异常和if...else进行性能对比：

public class CompareException {

    public static void main(String []args) {
        CompareException compareException = new CompareException();
        compareException.testException();
        compareException.testIfElse();
    }
    public String testException() {
        long now = System.currentTimeMillis();
        String ret = "";
        int b = 0;
        for (int i = 0; i < 1000000; i++) {
            try {
                if (b == 0) {
                    throw new Exception("参数错误");
                }
            } catch (Exception e) {
                //吞掉异常堆栈，不做任何处理
                ret = "参数错误";
            }
        }
        long cost = System.currentTimeMillis() - now;
        System.out.println("testException cost = " + cost);
        return ret;
    }
    public String testIfElse() {
        int b = 0;
        String ret = "";
        long now = System.currentTimeMillis();
        for (int i = 0; i < 1000000; i++) {
            if (b == 0) {
                ret = "参数错误";
            }
        }
        long cost = System.currentTimeMillis() - now;
        System.out.println("testIfElse cost = " + cost);
        return ret;
    }
}

输出如下，使用异常耗时远远大于普通的if...else...

testException cost = 1352 testIfElse cost = 8

从流程处理上，使用异常显然更加的清晰方便，主流程调用方法出现如参数错误，业务校验不通过的情况，可以返回给调用方法具体的错误原因。在这种我们只是想使用异常获取控制代码执行流程，获取具体流程变更原因的情况下，我们可以通过复写fillInStackTrace方法来减小上述性能开销。
下面我们新建一个业务异常类并复写fillInStackTrace方法如下：

public class BusinessException extends Exception {

    private String message;

    public BusinessException(String message) {
        super();
        this.message = message;
    }

    @Override
    public String getMessage() {
        return message;
    }

    public void setMessage(String message) {
        this.message = message;
    }

    public Throwable fillInStackTrace() {
        return this;
    }
}

我们将CompareException类中的testException 抛出BusinessException并重新进行性能比对结果如下，我们看到testException方法性能有了很大的改善。

testException cost = 48 testIfElse cost = 3

有了上面的分析，相信大家已经对我上面提出的问题有了答案，我们不能说哪种方式不好，重要的是要知道底层原理，根据系统的需要进行选择。

参考

https://chenyongjun.vip/articles/29
http://hinylover.space/2016/06/05/relearn-java-exception/

谈谈java的异常机制

谈谈java的异常机制

简介

java异常基础知识

java异常机制原理分析

参考

推荐阅读更多精彩内容