它基本上意味着：
将“ SomeExceptionType”捕获到变量“ e”中，并保证在处理异常期间不会为“ e”分配其他异常。
通常，这太过分了，好像我将一个异常捕获到一个临时变量名称中（e仅对异常处理块有效），我不必太严厉地监管自己以至于不信任自己来分配其他变量（可能会创建）相同变量名的异常。
就是说，这个障碍可能是由一群不同想法的团队高度维护的，一个人只是想非常确定e是最初捕获的异常。
-—根据评论进行编辑----
我想不出这样做的绝佳理由。由于“ e”不是成员（静态或其他），因此类文件在编译后将不使用名称“
e”。另一种说明方式是，当您输入JVM字节码的异常处理块时，该对象将不会分配给JVM处理框架可访问的任何成员名称，它将被推送到线程的内部处理堆栈中。当前帧。
即使两个线程可以访问同一对象，每个线程也将拥有自己的框架，因此编译器从一个框架的内部堆栈中删除了“ e”名称，而另一线程无法更改该名称。
考虑到这一点，声明“ e”为final的唯一好处是确保将来的编码人员在进入该代码块后不会意外地将其设置为“
e”。也许它们的目的是使代码在多线程环境中更健壮，但是临时变量（名称仅在块中有效的变量）在编译后没有名称，因此将它们压入框架的堆栈中。
这就是为什么
public int safe() { int x = 5; x = x + 5; return x;}通常被认为是线程安全的，因为它这样做（用伪字节码）
(In the thread's current frame)push 5push 5add integersreturn
虽然这不是线程安全的
int x = 5;public void unsafe() { x = 5; x = x + 5; return x;}因为这样做
(in the thread's current frame)push "this"push 5set member xpush "this"get member xpush 5add integerset member xget member xreturn
后一个字节码清楚地表明，交织两个线程使用成员x a中介创建线程到线程通信，而第一段代码不能进行任何线程间通信，因为没有中介。
