为什么抑制try-with-resource的异常以相反的执行顺序处理？

Question

在正常的try-catch-finally中,像这样,

try {
    throw new ExceptionA();
} finally {
    throw new ExceptionB();
}

ExceptionA在Exception B之前抛出.ExceptionA将被禁止.

但是在try-with-resource中,像这样,

try ( // declare resource that throw ExceptionA in close method ) {
    throw new ExceptionB();
}

ExceptionA在ExceptionB之后抛出.ExceptionA将被禁止.

为什么他们有不同的抑制异常的命令？

Answer 1

当你使用try并最终没有try-with-resources时,当try块中出现错误时,你会抛出一个异常,然后执行finally,如果在finally块期间抛出异常,则抛出异常最后屏蔽 try块抛出的异常."异常屏蔽"是JVM选择从try-finally抛出的异常是finally块中的异常,而不是原始异常的位置.这可能非常糟糕,因为try块抛出的异常是带有错误信息的异常,finally抛出的异常通常只是噪声.因此,在上面的示例A中,从实现者的角度来看,所发生的事情是直观的,但它对应用程序开发人员没有用处; 关于实际出错的有价值的信息是在A中而你丢失了,而抛出的是B和B的堆栈跟踪是你在阅读日志文件时看到的.

例如:我的代码发出一个JDBC调用,抛出一个带有行号的异常,告诉我错误发生的位置,以及我可以映射回供应商代码的SQLState,告诉我出了什么问题,但是当关闭语句或连接时有一个网络故障,因为JDBC对象告诉服务器服务器应该清理什么,并且我得到一个断管道异常.除非你对异常处理非常彻底,否则很容易用破坏的管道掩盖有用的异常,你不能做任何事情而不关心.

try-with-resources功能尝试确保信息性异常不会被关闭时抛出的偶然异常所掩盖,try块中抛出的异常是抛出的异常,而close方法抛出的异常是抑制,意味着它被添加到try块的异常中(除非try块中没有抛出任何内容,在这种情况下,close抛出的异常是被抛出的内容).

所以这是一个改变,但它在减少有价值的异常被无意中掩盖的可能性方面有了很大的改进.