finally中写return会覆盖异常处理结果，导致程序控制流混乱。

珍惜时间，勤奋学习！今天给大家带来《finally里写return会怎样？控制流冲突解析》，正文内容主要涉及到等等，如果你正在学习文章，或者是对文章有疑问，欢迎大家关注我！后面我会持续更新相关内容的，希望都能帮到正在学习的大家！

finally中写return会强制使方法返回其值并吞掉异常。例如try返回1、finally返回2则实际返回2；try抛异常、finally返回42则异常消失，仅返回42。这是JVM控制流机制决定的，非覆盖行为，但严重破坏可读性与异常传播，不推荐使用。

在Java中，finally块里写return会导致try或catch中的return被忽略，方法会直接返回finally中的值。这不是“覆盖”，而是控制流的强制转移——JVM会确保finally执行完毕，并以其中的return为最终出口。

finally里的return会屏蔽try/catch的return

只要finally中有return语句，无论try或catch是否已执行了return，JVM都会丢弃之前准备好的返回值，转而执行finally中的return，并将其作为方法的最终返回结果。

• try中return 1；finally中return 2 → 实际返回2
• catch中return -1；finally中return 0 → 实际返回0
• 即使try/catch抛出异常，只要finally有return，异常也会被“吞掉”，方法正常返回

异常会被finally中的return压制

如果try或catch抛出了未捕获的异常，但finally中执行了return，该异常将不会向上传播，调用方收不到异常，只会得到finally的返回值。这极易掩盖问题。

• try中throw new RuntimeException("oops")
• finally中return 42
• 结果：方法返回42，异常消失，调用方完全不知发生了错误

不推荐在finally中写return

这是Java编程规范明确反对的做法。它破坏了方法的可读性、可预测性和异常传播逻辑，容易引发隐蔽bug。

• 清理资源（如close流、释放锁）应放在finally中，但不要加return
• 需要统一返回值，应在try/catch外定义变量，在finally中只做清理，最后return该变量
• 若真需在finally中干预返回逻辑，应使用try-with-resources或显式状态标记，而非return

字节码层面的真相

编译后，javac会把try/catch/finally合并为一个结构化异常表，并为每个可能出口插入“finally代码副本”。当遇到return时，JVM先暂存返回值，再跳入finally执行；若finally内有return，则直接用其操作数栈顶值作为最终返回，原暂存值被丢弃。

• 也就是说，finally中的return不是“后来者居上”，而是JVM控制流机制的必然行为
• 这也是为什么即便在finally中修改了局部变量，也不影响已暂存的返回值（除非你又写了return）

终于介绍完啦！小伙伴们，这篇关于《finally中写return会覆盖异常处理结果，导致程序控制流混乱。》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！