我正在检查 Java SE7 的新功能，我目前处于这一点：
http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html
关于 catch multiple 功能，当我遇到这个声明时：
注意：如果一个 catch 块处理多个异常类型，则 catch 参数是隐式 final 的。在此示例中，catch 参数 ex 是最终参数，因此您不能在 catch 块中为其分配任何值。
我从来没有注意到在处理捕获的异常的经典案例中捕获的异常不是最终的。
我只是想知道为什么这首先是一件好事？在我猜想重新抛出它或者记录它的消息之前，本质上修改一个捕获的异常不是不明智的吗？是否应该由 trowing 机制来创建异常，以便它准确地代表它应该做什么？
我从未见过在 catch 块中修改异常，也许有人能指出它的好处？
它与方法参数几乎相同：
您通常不会修改它们，并且许多人同意应该将它们视为final（是否实际final在它们面前写是有争议的）。
但是由于没有技术要求说它必须是final，因此该语言为您提供了选择的选项。
就我个人而言，我知道没有充分的理由来修改 catch 块的异常引用。
我想不出一个令人信服的用例来修改经典catch子句中的异常。然而，这并不意味着它应该被禁止。特别是考虑到您可以修改参数变量。如果您觉得这令人担忧，您可以选择将异常变量声明为final.
另一方面，允许修改多异常捕获将引入真正奇怪和令人困惑的代码的可能性，例如：
catch (IOException | NullPointerException ex) {
...
ex = new IllegalArgumentException(...);
}
我想这就是设计师在这种情况下添加限制时的想法。
但无论哪种方式，这都是 Java 语言的定义方式，也是我们必须忍受的。辩论明显的不一致没有太多意义……除非您打算设计和实现一种新语言。
我能想到最终强制执行它的原因是由于性能。一旦捕获评估开始，在评估机制中具有最终不可变值可确保更快地评估所有捕获。由于 try-catch 在任何 Java 代码中都广泛使用，因此最好采用最高性能的设计。
基于以上所述，这意味着影响大多数程序的性能改进。
基于异常的错误处理背后的想法是，如果可能的话，应该在适当的抽象级别上恢复每个错误。这种错误恢复可能需要在实际处理异常时无法直接获得的信息。出于这个原因，捕获异常可能很方便，用相关信息对其进行扩充并重新抛出它，或者可能将其设置为更合适类的新异常对象的原因。