Java catch块，捕获exception不是最终的

我正在查看Java SE7的新function，目前我正在这里：

http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html

关于catch多function，当我遇到这个声明时：

注意：如果catch块处理多个exception类型，则catch参数隐式为final。 在此示例中，catch参数ex是final，因此您无法在catch块中为其分配任何值。

我从未注意到在处理捕获的exception的经典案例中，捕获的exception不是最终的。

我只是想知道为什么这首先是一件好事？ 在猜测重新抛出它或者记录它的消息之前，对于一个被捕获的exception进行必要的修改是不是不明智？ 是否应该由创建exception的trowing机制来完成它应该代表什么呢？

我从来没有看到在catch块中修改exception可能有人指出它的好处？

谢谢！

Answer 1

它与方法参数几乎相同：

你通常不会修改它们， 很多人都认为它们应该被视为final （无论是否真正在他们面前写final都是一个争论的问题）。

但由于没有技术要求表明它必须是final ，因此该语言可让您选择。

我个人认为没有理由修改catch-block的exception引用。

Answer 2

我无法想象一个令人信服的用例来修改经典catch子句中的exception。 但是，这并不意味着它应该被禁止。 特别是假设您可以修改参数变量。 如果您发现这令人担忧，您可以选择将exception变量声明为final 。

另一方面，允许修改多exception捕获会引入真正奇怪和令人困惑的代码的可能性，例如：

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

我想这就是设计师在这种情况下加入限制时的想法。

但不管怎样，这就是Java语言的定义方式，以及我们必须接受的内容。 除非你打算设计和实现一种新语言，否则在讨论明显的不一致性方面没有太多意义。

Answer 3

我可以想到最终执行它的原因是由于性能。 一旦捕获评估开始，在评估机制中具有最终的不可变值可确保更快地评估所有捕获量。 由于try-catch在任何Java代码中都被广泛使用，因此最高性能的设计更为可取。

基于以上所述，它意味着性能的提高会影响大多数程序。

Answer 4

基于exception的error handling背后的想法是，如果可能的话，应该在适当的抽象级别恢复每个错误。 此类错误恢复可能需要在实际处理exception的情况下无法直接获得的信息。 由于这个原因，捕获exception可能很方便，用相关信息扩充它并重新抛出它或者可能将它设置为更合适的类的新exception对象的原因。