内联最后的块
您提出的问题已在http://devblog.guidewire.com/2009/10/22/compiling-trycatchfinally-on-
the-
jvm/中进行了部分分析（回溯机器Web归档链接）
该帖子将显示一个有趣的示例以及诸如（quote）之类的信息：
通过在try或关联的catch块的所有可能的出口处内联final代码，然后将整个内容包装在本质上是“
catch（Throwable）”块中，该代码在完成时重新抛出异常，然后调整异常表，从而实现了finally块catch子句会跳过内联的finally语句。?？（需要注意的是：在1.6编译器之前，显然，finally语句使用子例程而不是完整的代码内联。但是此时我们仅关注1.6，因此适用于此）。
JSR指令和内联最后
关于为什么使用内联的观点存在分歧，尽管我尚未从官方文档或来源中找到确定的内联。
有以下3种解释：
没有报价优势-麻烦更多：
有些人认为最终使用内联是因为JSR /RET并没有提供主要优势，例如引述了哪些Java编译器使用jsr指令，以及为什么？
JSR / RET机制最初用于实现finally块。但是，他们认为节省代码大小并不值得额外的复杂性，因此逐渐被淘汰了。
使用堆栈映射表进行验证的问题：
@ jeffrey-bosboom在评论中提出了另一种可能的解释，我在下面引用：
javac曾经使用jsr（跳转子例程）只编写一次final代码，但是使用堆栈映射表进行新的验证存在一些问题。我认为他们只是因为这是最容易的事情而回到克隆代码。
必须维护子例程脏位：
在问题注释中进行了有趣的交流，哪些Java编译器使用jsr指令，以及用于什么目的？指出，JSR和子例程“由于必须为局部变量维护一堆脏位而增加了额外的复杂性”。
下面交流：
@
paj28：如果jsr只能调用已声明的“子例程”，那么每个jsr都会造成此类困难，每个子例程只能在开始时输入，只能从另一个子例程调用，并且只能通过ret或突然完成退出（返回还是抛出）？在finally块中复制代码确实很丑陋，尤其是由于与final相关的清除操作可能经常调用嵌套的try块。–
2014年1月28日在23:18的超级猫@supercat，大多数已经是真的。子例程只能从头开始输入，只能从一个位置返回，并且只能在单个子例程中调用。
复杂性来自以下事实：您必须维护一堆用于局部变量的脏位，并且在返回时必须进行三向合并。 –锑2014年1月28日23:40
