On Mon, 16 Oct 2023 23:56:24 GMT, Stuart Marks <sma...@openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   retained a reference to the RMI server and improved naming
>
> test/lib/jdk/test/lib/Asserts.java line 588:
> 
>> 586:         }
>> 587:         // fail() throws a RuntimeException so this is unreachable.
>> 588:         return null;
> 
> Hm, this is unfortunate. Even though this method throws along all code paths, 
> the compiler doesn't do this analysis. Even though this "never happens" 
> there's still a question of "but what if?" (I guess it could happen if 
> somebody in the future were to modify the code above.) I'd suggest 
> unconditionally throwing an exception here (probably InternalError) to be 
> more explicit. Returning null will result in an inexplicable NPE if somebody 
> dereferences the return value.

Actually, this is a mistake. If I call `fail()` immediately after the test 
method executes (because an exception wasn't thrown), the RuntimeException 
which will promptly be caught in my try/catch and that isn't what we want. I'm 
moving that invocation to the end which looks and works a lot better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1361958521

Reply via email to