On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kev...@openjdk.org> wrote:
> Exceptions during setup of these tests could leave e.g. JMXConnector cs as > null. > But, we call cs.close() during a finally block and fail with an NPE, > obscuring the real failure. > We must only call close if this is not null. Yes, that's exactly what's happening... The NPEs on the connection stop us seeing an earlier Error from e.g. the connection attempt, and an NPE is reported as the reason for the test failure. If I add a "throw new OutOfMemoryError" before it makes the connection, then that is not seen with the original version, just the misleading NPE on the cleanup attempt in the finally block. With the new null checks, that OutOfMemoryError is reported by the test harness as the reason for the test failure (JavaTest Message: Test threw exception: java.lang.OutOfMemoryError). This seems like the kind of Error the test harness should be reporting for us (I don't think the test should necessarily catch Throwable/Error, but it should be well-behaved in its finally). ------------- PR: https://git.openjdk.org/jdk/pull/11881
