RFR: 8169475 : WheelModifier.java fails by timeout

Phil Race prr at openjdk.org
Fri Oct 20 21:42:35 UTC 2023


On Fri, 20 Oct 2023 11:42:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/java/awt/event/MouseWheelEvent/WheelModifier/WheelModifier.java line 173:
>> 
>>> 171:             test.run();
>>> 172:         } finally {
>>> 173:             SwingUtilities.invokeAndWait(test.f::dispose);
>> 
>> It would be good to ensure that f is not NULL before dispose.
>
>> It would be good to ensure that f is not NULL before dispose.
> 
> I know we're doing it all the time… But is it really relevant?
> 
> This has been bothering me for a while now… Let's clear things up.
> 
> If the frame is `null`, something has gone awry. If the test code itself didn't throw the exception, we'll get:
> 
> 
> Exception in thread "main" java.lang.NullPointerException
>         at WheelModifier.main(WheelModifier.java:173)
> 
> 
> The bad thing is that any exception thrown from the test itself — in the `try` block — gets overridden by the exception thrown from the `finally` block. Thus, we get the same exception as above.
> 
> The overall result is that the test fails, yet it may hide the real reason, which makes it harder to analyse the root cause of the failure.
> 
> Taking into account the above, *`null`-check is good even though it makes the code longer.*

Yes, if we have a null frame, I'd like to think that there's already an exception thrown by a well written test,
and a finally block isn't normally the place you'd want to have an accidental exception generated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16281#discussion_r1367502914


More information about the client-libs-dev mailing list