java异常分类和finally代码块中return语句的影响

风和树里

已于 2023-03-02 11:25:23 修改

阅读量658

点赞数 1

分类专栏： java 文章标签： java 异常分类 finally代码块

于 2023-03-02 09:23:54 首次发布

本文链接：https://blog.csdn.net/baidu_40120883/article/details/129291025

版权

java 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

首先看一下java中异常相关类的继承关系：

引用

1、分类

异常可以分为受查异常和非受查异常，Error和RuntimeException及其所有的子类都是非受查异常，其他的是受查异常。
两者的区别主要在：

受检的异常是由编译器（编译阶段）强制执行的，必须try-catch捕获或者往上抛出，用于指示不受程序控制的异常情况（例如，I/O 错误）。
而非受检的异常在运行时发生，用于指示编程错误（例如，空指针。正因为如此，受检异常在使用的时候需要比非受检异常更多的代码来避免编译错误。

常见的异常有：
在这里插入图片描述
之所以要定义受检异常和非受检异常主要是因为两者有着不同的作用

在程序中，存在一些需要用户在编译期间就去检查的问题，比如FileNotFoundException、IOException，这些异常涉及资源处理，调用者需要捕获，其实它可以提醒开发者，如果被调用的方法出现这类异常时，程序应该做好预判并处理，比如IOExcetion，我们需要对流进行关闭操作。
而非受检发生在运行期间，是程序运行过程中可能发生的错误类型，比如NullpointExcetpion，这些异常我们可以捕获，也可以不捕获。但是捕获这些异常只能打印一些日志，除此之外什么都做不了。（捕获了也无法在程序中解决）

2、finally与return

2.1 finally原理

public class Demo3_11_4 {
  public static void main(String[] args) {
    int i = 0;
    try {
    	i = 10;
    } catch (Exception e) {
    	i = 20;//异常表中有3行，分别是监测try中出现的异常、catch中出现的异常（catch中处理异常时也是可能产生异常的）
    } finally {
    	i = 30;
    }
    System.out.println(i);
  }
}
//输出：30

字节码：
在这里插入图片描述
可以看到在字节码中 finally 中的代码被复制了 3 份，分别放入 try 流程，catch 流程以及 catch 剩余的异常类型流程。当catch中代码出现异常时，该异常对象会被抛出。

2.2 finally 对返回值影响

finally中return

public class Demo3_12_2 {
  public static void main(String[] args) {
    int result = test();
    System.out.println(result);
  }
  public static int test() {
    try {
    	return 10;
    } finally {
    	return 20;
    }
  }
}
//输出 20

字节码

//字节码指令
public static int test();
  descriptor: ()I
  flags: ACC_PUBLIC, ACC_STATIC
  Code:
    stack=1, locals=2, args_size=0
      0: bipush 10 // <- 10 放入栈顶
      2: istore_0 // 10 -> slot 0 (从栈顶移除了，后面还有字节码，不能return)
      3: bipush 20 // <- 20 放入栈顶
      5: ireturn // 返回栈顶 int(20)
      6: astore_1 // catch any -> slot 1
      7: bipush 20 // <- 20 放入栈顶
      9: ireturn // 返回栈顶 int(20)
  Exception table:
    from to target type
    0 	 3	 	6		 any
  LineNumberTable: ...
  StackMapTable: ...

由于 finally 中的 ireturn 被插入了所有可能的流程，因此返回结果肯定以 finally 的为准

try中return，finally中修改return值

public class Demo3_12_2 {
  public static void main(String[] args) {
    int result = test();
    System.out.println(result);
  }
  public static int test() {
    int i = 10;
    try {
    	return i;
    } finally {
    	i = 20;
    }
  }
}

//输出10

字节码：

可以看到，在try中执行return时已经暂存的i=10，后续修改i不会改变本地变量表中的i。

2.3 finally中return对异常的影响

在2.1中我们可以看到，为了防止catch捕获异常处理的过程中产生异常后直接抛出而不执行finally中的代码，因此在字节码中，对try中代码也进行了异常的跟踪，并最后抛了出去。

有如下代码：

public class Demo3_12_2 {
  public static void main(String[] args) {
    int result = test();
    System.out.println(result);
  }
  public static int test() {
    int i = 10;
    try {
    	i = 1/0;
    	return i;
    } finally {
    	i = 20;
    	//return i;
    }
  }
}
//输出：30

问题1：会抛出异常吗？

public static int test();
    descriptor: ()I
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=3, args_size=0
         0: bipush        10
         2: istore_0
         3: iconst_1
         4: iconst_0
         5: idiv
         6: istore_0
         7: iload_0
         8: istore_1
         9: bipush        20			-----------
        11: istore_0
        12: iload_1
        13: ireturn						-----------
        14: astore_2
        15: bipush        20			-----------
        17: istore_0
        18: aload_2
        19: athrow
      Exception table:
         from    to  target type
             3     9    14   any

从字节码中可以看到，当前代码在try中——字节码3到9（不包括9），出现异常会直接跳到14，将异常对象放到slot2，然后执行finally代码，将20->i，抛出异常对象。所以时可以抛出异常的。

问题2：finally中添加return后会抛出异常吗？

  public static int test();
    descriptor: ()I
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=3, args_size=0
         0: bipush        10
         2: istore_0
         3: iconst_1
         4: iconst_0
         5: idiv
         6: istore_0
         7: iload_0
         8: istore_1
         9: bipush        20
        11: istore_0
        12: iload_0
        13: ireturn
        14: astore_2
        15: bipush        20
        17: istore_0
        18: iload_0
        19: ireturn
      Exception table:
         from    to  target type
             3     9    14   any