它与方法参数基本相同：
你通常不会修改它们，很多人都认为它们应该被视为 final （是否实际写作） final 摆在他们面前的是一个有争议的问题）。
但既然没有技术要求 final ，您可以选择语言。
就我个人而言，我不知道有什么好的理由来修改catch块的异常引用。

基于异常的错误处理背后的思想是，如果可能的话，应该在适当的抽象级别上恢复每个错误。这种错误恢复可能需要在实际处理异常的地方无法直接获得的信息。出于这个原因，捕获异常、用相关信息扩充异常并重新引用它或可能将其设置为更合适类的新异常对象的原因可能是很方便的。

我之所以能想到强制执行它是因为性能。一旦渔获量评估开始，在评估机制中有一个最终不变的值可以确保更快地评估所有渔获量。由于try-catch在所有java代码中都被广泛使用，因此最好采用最高性能的设计。
基于以上，它意味着性能的提高，影响到大多数程序。

我想不出一个令人信服的用例来修改经典中的异常 catch 条款。然而，这并不意味着它应该被禁止。特别是你可以修改一个参数变量。如果您发现这一点令人担忧，您可以选择将异常变量声明为 final .
另一方面，允许修改multi-exception-catch将引入真正奇怪和混乱的代码的可能性，例如：

catch (IOException | NullPointerException ex) {
      ...
      ex = new IllegalArgumentException(...);
  }

我想这就是设计师们在本例中添加限制时的想法。
但不管怎样，这就是java语言的定义，也是我们必须面对的。争论这些明显的不一致没有多大意义。。。除非你打算设计和实现一种新的语言。