try-catch-finally中的4个大坑,不小心就栽进去了!
在 Java 语言中 try-catch-finally 看似简单,一副人畜无害的样子,但想要真正的“掌控”它,却并不是一件容易的事。别的不说,咱就拿 fianlly 来说吧,别看它的功能单一,但使用起来却“暗藏杀机”,若您不信,咱来看下面的这几个例子...
坑1:finally中使用return
若在 finally 中使用 return,那么即使 try-catch 中有 return 操作,也不会立马返回结果,而是再执行完 finally 中的语句再返回。此时问题就产生了:如果 finally 中存在 return 语句,则会直接返回 finally 中的结果,从而无情的丢弃了 try 中的返回值。
① 反例代码
public static void main(String[] args) throws FileNotFoundException {
System.out.println("执行结果:" + test());
}
private static int test() {
int num = 0;
try {
// num=1,此处不返回
num++;
return num;
} catch (Exception e) {
// do something
} finally {
// num=2,返回此值
num++;
return num;
}
}
以上代码的执行结果如下:
② 原因分析
如果在 finally 中存在 return 语句,那么 try-catch 中的 return 值都会被覆盖,如果程序员在写代码的时候没有发现这个问题,那么就会导致程序的执行结果出错。
③ 解决方案
如果 try-catch-finally 中存在 return 返回值的情况,一定要确保 return 语句只在方法的尾部出现一次。
④ 正例代码
public static void main(String[] args) throws FileNotFoundException {
System.out.println("执行结果:" + testAmend());
}
private static int testAmend() {
int num = 0;
try {
num = 1;
} catch (Exception e) {
// do something
} finally {
// do something
}
// 确保 return 语句只在此处出现一次
return num;
}
坑2:finally中的代码“不执行”
如果说上面的示例比较简单,那么下面这个示例会给你不同的感受,直接来看代码。
① 反例代码
public static void main(String[] args) throws FileNotFoundException {
System.out.println("执行结果:" + getValue());
}
private static int getValue() {
int num = 1;
try {
return num;
} finally {
num++;
}
}
以上代码的执行结果如下:
② 原因分析
**本以为执行的结果会是 2,但万万没想到竟然是 1 **,用马大师的话来讲:「我大意了啊,没有闪」。
有人可能会问:如果把代码换成 ++num,那么结果会不会是 2 呢?
很抱歉的告诉你,并不会,执行的结果依然是 1。那为什么会这样呢?想要真正的搞懂它,我们就得从这段代码的字节码说起了。
以上代码最终生成的字节码如下:
// class version 52.0 (52)
// access flags 0x21
public class com/example/basic/FinallyExample {
// compiled from: FinallyExample.java
// access flags 0x1
public <init>()V
L0
LINENUMBER 5 L0
ALOAD 0
INVOKESPECIAL java/lang/Object.<init> ()V
RETURN
L1
LOCALVARIABLE this Lcom/example/basic/FinallyExample; L0 L1 0
MAXSTACK = 1
MAXLOCALS = 1
// access flags 0x9
public static main([Ljava/lang/String;)V throws java/io/FileNotFoundException
L0
LINENUMBER 13 L0
GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
NEW java/lang/StringBuilder
DUP
INVOKESPECIAL java/lang/StringBuilder.<init> ()V
LDC "\u6267\u884c\u7ed3\u679c:"
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
INVOKESTATIC com/example/basic/FinallyExample.getValue ()I
INVOKEVIRTUAL java/lang/StringBuilder.append (I)Ljava/lang/StringBuilder;
INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/String;)V
L1
LINENUMBER 14 L1
RETURN
L2
LOCALVARIABLE args [Ljava/lang/String; L0 L2 0
MAXSTACK = 3
MAXLOCALS = 1
// access flags 0xA
private static getValue()I
TRYCATCHBLOCK L0 L1 L2 null
L3
LINENUMBER 18 L3
ICONST_1
ISTORE 0
L0
LINENUMBER 20 L0
ILOAD 0
ISTORE 1
L1
LINENUMBER 22 L1
IINC 0 1
L4
LINENUMBER 20 L4
ILOAD 1
IRETURN
L2
LINENUMBER 22 L2
FRAME FULL [I] [java/lang/Throwable]
ASTORE 2
IINC 0 1
L5
LINENUMBER 23 L5
ALOAD 2
ATHROW
L6
LOCALVARIABLE num I L0 L6 0
MAXSTACK = 1
MAXLOCALS = 3
}
这些字节码的简易版本如下图所示:
想要读懂这些字节码,首先要搞懂这些字节码所代表的含义,这些内容可以从 Oracle 的官网查询到(英文文档):https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html
磊哥在这里对这些字节码做一个简单的翻译:
iconst 是将 int 类型的值压入操作数栈。
istore 是将 int 存储到局部变量。
iload 从局部变量加载 int 值。
iinc 通过下标递增局部变量。
ireturn 从操作数堆栈中返回 int 类型的值。
astore 将引用存储到局部变量中。
有了这些信息之后,我们来翻译一下上面的字节码内容:
0 iconst_1 在操作数栈中存储数值 1
1 istore_0 将操作数栈中的数据存储在局部变量的位置 0
2 iload_0 从局部变量读取值到操作数栈
3 istore_1 将操作数栈中存储 1 存储在局部变量的位置 1
4 iinc 0 by 1 把局部变量位置 0 的元素进行递增(+1)操作
7 iload_1 将局部位置 1 的值加载到操作数栈中
8 ireturn 返回操作数栈中的 int 值
通过以上信息也许你并不能直观的看出此方法的内部执行过程,没关系磊哥给你准备了方法执行流程图:
通过以上图片我们可以看出:在 finally 语句(iinc 0, 1)执行之前,本地变量表中存储了两个信息,位置 0 和位置 1 都存储了一个值为 1 的 int 值。而在执行 finally(iinc 0, 1)之前只把位置 0 的值进行了累加,之后又将位置 1 的值(1)返回给了操作数栈,所以当执行返回操作(ireturn)时会从操作数栈中读到返回值为 1 的结果,因此最终的执行是 1 而不是 2。
③ 解决方案
关于 Java 虚拟机是如何编译 finally 语句块的问题,有兴趣的读者可以参考《The JavaTM Virtual Machine Specification, Second Edition》中 7.13 节 Compiling finally。那里详细介绍了 Java 虚拟机是如何编译 finally 语句块。
实际上,Java 虚拟机会把 finally 语句块作为 subroutine(对于这个 subroutine 不知该如何翻译为好,干脆就不翻译了,免得产生歧义和误解)直接插入到 try 语句块或者 catch 语句块的控制转移语句之前。但是,还有另外一个不可忽视的因素,那就是在执行 subroutine(也就是 finally 语句块)之前,try 或者 catch 语句块会保留其返回值到本地变量表(Local Variable Table)中,待 subroutine 执行完毕之后,再恢复保留的返回值到操作数栈中,然后通过 return 或者 throw 语句将其返回给该方法的调用者(invoker)。
因此如果在 try-catch-finally 中如果有 return 操作,一定要确保 return 语句只在方法的尾部出现一次!这样就能保证 try-catch-finally 中所有操作代码都会生效。
④ 正例代码
private static int getValueByAmend() {
int num = 1;
try {
// do something
} catch (Exception e) {
// do something
} finally {
num++;
}
return num;
}
坑3:finally中的代码“非最后”执行
① 反例代码
public static void main(String[] args) throws FileNotFoundException {
execErr();
}
private static void execErr() {
try {
throw new RuntimeException();
} catch (RuntimeException e) {
e.printStackTrace();
} finally {
System.out.println("执行 finally.");
}
}
以上代码的执行结果如下:
从以上结果可以看出 finally 中的代码并不是最后执行的,而是在 catch 打印异常之前执行的,这是为什么呢?
② 原因分析
产生以上问题的真实原因其实并不是因为 try-catch-finally,当我们打开 e.printStackTrace 的源码就能看出一些端倪了,源码如下:
从上图可以看出,当执行 e.printStackTrace() 和 finally 输出信息时,使用的并不是同一个对象。finally 使用的是标准输出流:System.out,而 e.printStackTrace() 使用的却是标准错误输出流:System.err.println,它们执行的效果等同于:
public static void main(String[] args) {
System.out.println("我是标准输出流");
System.err.println("我是标准错误输出流");
}
而以上代码执行结果的顺序也是随机的,而产生这一切的原因,我们或许可以通过标准错误输出流(System.err)的注释和说明文档中看出:
我们简单的对以上的注释做一个简单的翻译:
“标准”错误输出流。该流已经打开,并准备接受输出数据。
通常,此流对应于主机环境或用户指定的显示输出或另一个输出目标。按照惯例,即使主要输出流(out 输出流)已重定向到文件或其他目标位置,该输出流(err 输出流)也能用于显示错误消息或其他信息,这些信息应引起用户的立即注意。
从源码的注释信息可以看出,标准错误输出流(System.err)和标准输出流(System.out)使用的是不同的流对象,即使标准输出流并定位到其他的文件,也不会影响到标准错误输出流。那么我们就可以大胆的猜测:二者是独立执行的,并且为了更高效的输出流信息,二者在执行时是并行执行的,因此我们看到的结果是打印顺序总是随机的。
为了验证此观点,我们将标准输出流重定向到某个文件,然后再来观察 System.err 能不能正常打印,实现代码如下:
public static void main(String[] args) throws FileNotFoundException {
// 将标准输出流的信息定位到 log.txt 中
System.setOut(new PrintStream(new FileOutputStream("log.txt")));
System.out.println("我是标准输出流");
System.err.println("我是标准错误输出流");
}
以上代码的执行结果如下:
当程序执行完成之后,我们发现在项目的根目录出现了一个新的 log.txt 文件,打开此文件看到如下结果:
从以上结果可以看出标准输出流和标准错误输出流是彼此独立执行的,且 JVM 为了高效的执行会让二者并行运行,所以最终我们看到的结果是 finally 在 catch 之前执行了。
③ 解决方案
知道了原因,那么问题就好处理,我们只需要将 try-catch-finally 中的输出对象,改为统一的输出流对象就可以解决此问题了。
④ 正例代码
private static void execErr() {
try {
throw new RuntimeException();
} catch (RuntimeException e) {
System.out.println(e);
} finally {
System.out.println("执行 finally.");
}
}
改成了统一的输出流对象之后,我手工执行了 n 次,并没有发现任何问题。
坑4:finally中的代码“不执行”
finally 中的代码一定会执行吗?如果是之前我会毫不犹豫的说“是的”,但在遭受了社会的毒打之后,我可能会这样回答:正常情况下 finally 中的代码一定会执行的,但如果遇到特殊情况 finally 中的代码就不一定会执行了,比如下面这些情况:
- 在 try-catch 语句中执行了 System.exit;
- 在 try-catch 语句中出现了死循环;
- 在 finally 执行之前掉电或者 JVM 崩溃了。
如果发生了以上任意一种情况,finally 中的代码就不会执行了。虽然感觉这一条有点“抬杠”的嫌疑,但墨菲定律告诉我们,如果一件事有可能会发生,那么他就一定会发生。所以从严谨的角度来说,这个观点还是成立的,尤其是对于新手来说,神不知鬼不觉的写出一个自己发现不了的死循环是一件很容易的事,不是嘛?
① 反例代码
public static void main(String[] args) {
noFinally();
}
private static void noFinally() {
try {
System.out.println("我是 try~");
System.exit(0);
} catch (Exception e) {
// do something
} finally {
System.out.println("我是 fially~");
}
}
以上代码的执行结果如下:
从以上结果可以看出 finally 中的代码并没有执行。
② 解决方案
排除掉代码中的 System.exit 代码,除非是业务需要,但也要注意如果在 try-cacth 中出现了 System.exit 的代码,那么 finally 中的代码将不会被执行。
总结
本文我们展示了 finally 中存在的一些问题,有很实用的干货,也有一些看似“杠精”的示例,但这些都从侧面印证了一件事,那就是想完全掌握的 try-catch-finally 并不是一件简单的事。最后,在强调一点,如果 try-catch-finally 中存在 return 返回值的操作,那么一定要确保 return 语句只在方法的尾部出现一次!
参考 & 鸣谢
阿里巴巴《Java开发手册》
developer.ibm.com/zh/articles/j-lo-finally
关注公众号「Java中文社群」发现更多干货。
查看 Github 发现更多精彩:https://github.com/vipstone/algorithm
try-catch-finally中的4个大坑,不小心就栽进去了!的更多相关文章
- Java异常处理中finally中的return会覆盖catch语句中的return语句
Java异常处理中finally中的return会覆盖catch语句中的return语句和throw语句,所以Java不建议在finally中使用return语句 此外 finally中的throw语 ...
- 一个问题:关于finally中return吞掉catch块中抛出的异常
今天遇到一个感觉很神奇的问题,记录一下问题以及自己分析问题的思路. 预警:不知道怎么看java字节码的朋友可能需要先看一下如何阅读java字节码才能看懂后面的解释. 我有一段程序: public cl ...
- try catch finally 中包含return的几种情况,及返回结果
当当当,兴致勃勃的第二篇博客,散花~ 下面是正题(敲黑板) 第一种情况:在try和catch中有return,finally中没有return,且finally中没有对try或catch中要 retu ...
- catch/finally中不应使用 writer.flush()
在开发中遇到了一个问题,关闭流的时候会出现某种莫名其妙的错误.后来一个巧合看到了这个解决方法. 先看问题(知道答案以后,才知道是这里出错了) FileWriter writer = null; Str ...
- try catch finally 中 returne的执行顺序
结论:1.不管有没有出现异常,finally块中代码都会执行:2.当try和catch中有return时,finally仍然会执行:3.finally是在return后面的表达式运算后执行的(此时并没 ...
- 【手记】小心在where中使用NEWID()的大坑 【手记】解决启动SQL Server Management Studio 17时报Cannot find one of more components...的问题 【C#】组件分享:FormDragger窗体拖拽器 【手记】注意BinaryWriter写string的小坑——会在string前加上长度前缀length-prefixed
[手记]小心在where中使用NEWID()的大坑 这个表达式: ABS(CHECKSUM(NEWID())) % 3 --把GUID弄成正整数,然后取模 是随机返回0.1.2这三个数,不可能返回其它 ...
- try~Catch语句中异常的处理过程
[2014/10/12 21:40]文章待续~ 1.函数自身捕获处理异常的情况 以下的样例介绍了try~catch语句中出现异常时语句的运行顺序: package month10; import ja ...
- 关于try...catch...finally中return的疑惑
原文:http://www.cnblogs.com/and_he/archive/2012/04/17/2453703.html 关于try...catch...finally里面的return一直是 ...
- 在try...catch语句中执行Response.End()后如何停止执行catch语句中的内容
在调用Response.End()时,会执行Thread.CurrentThread.Abort()操作. 如果将Response.End()放在try...catch中,catch会捕捉Thread ...
随机推荐
- 前台js获取url传递参数(后台Request.QueryString接收)
方法 封装 function GetQueryString(name) { var reg = new RegExp("(^|&)" + name + "=([^ ...
- axios前端加密通讯的处理
axios前端加密通讯的处理 今天谈一谈前段时间,项目中遇见的前端axios加解密的处理. 先谈谈项目前景,因为安全的要求,所以我们要把前端所有的请求都得加密与服务端应用进行通讯,当然服务端的响应也是 ...
- springboot项目中使用jsp
在pom文件中 1.方法一 <!-- 引入tomcate内嵌的jsp解析包--> <dependency> <groupId>org.apache.tomcat.e ...
- [NOIP2013 提高组] 货车运输
前言 使用算法:堆优化 \(prim\) , \(LCA\) . 题意 共有 \(n\) 个点,有 \(m\) 条边来连接这些点,每条边有权值.有 \(q\) 条类似于 \(u\) \(v\) 询问, ...
- 学习Promise异步编程
JavaScript引擎建立在单线程事件循环的概念上.单线程( Single-threaded )意味着同一时刻只能执行一段代码.所以引擎无须留意那些"可能"运行的代码.代码会被放 ...
- TurtleBot3 Waffle (tx2版华夫)(6)
重要提示:请在配网通信成功后进行操作,配网后再次开机需要重新验证通信: 重要提示:[Remote PC]代表PC端.[TurtelBot]代表树莓派端: 操作步骤如下: 1)[Remote PC] 启 ...
- 在 CAP 中使用 AOP ( Castle.DynamicProxy )
简介 本篇文章主要介绍如何在 CAP 中集成使用 Castle.DynamicProxy,Castle DynamicProxy 是一个用于在运行时动态生成轻量级.NET代理的库.代理对象允许在不修改 ...
- redis数据类型:String
redis数据类型:String 花开堪折直需折,莫待无花空折枝 实际应用中有多种多样的场景,比如: 秒杀 新闻热点 在线人数 session.token管理 各个场景需要的数据类型各不相同:常见的数 ...
- MongoDB备份(mongodump)与恢复(mongorestore)工具实践
mongodump和mongorestore实践 1.mongodump备份工具 mongodump能够在Mongodb运行时进行备份,它的工作原理是对运行的Mongodb做查询,然后将所有查到的文档 ...
- Mac配置jmeter环境变量
#JAVA_HOME#JMETER_HOMEexport JAVA_8_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_211.jdk/Contents ...