On Tue, 5 Aug 2025 20:29:08 GMT, Archie Cobbs <aco...@openjdk.org> wrote:
>> Regardless of an interrupt, the process is destroyed, so there is no use to
>> propagate the interrupt.
>> It is debatable, whether or not and for how long to give the process time to
>> exit on its own.
>> If the process has any of its state (files or sockets, etc.) to cleanup,
>> destroying it might leave it in an unexpected state. All of the file
>> descriptors/handles will be closed by the OS, but files might have been
>> created. A robustly written application would/should be coded to deal with
>> that inconsistent persistent state.
>> The Java process invoking the child can use `waitFor` get the exit status
>> and wait for exit; generally it should not need to know anything about the
>> child process.
>
>> Regardless of an interrupt, the process is destroyed, so there is no use to
>> propagate the interrupt.
>
> While it's true that it doesn't matter if the purpose of the interruption was
> only to interrupt the `close()` invocation, couldn't this `close()` operation
> be one of several different "shutdown" actions the thread is taking, some of
> which do throw `InterruptedException`, in which the purpose of the
> interruption is to interrupt any or all of them? In that case, you'd want the
> interrupt to "hang around" so it can happen if/when the next interruptible
> operation occurs.
>
> In the example below, if the interruption just happens to occur during
> `Process.close()`, you want an `InterruptedException` to be thrown by
> `thing3.shutdown()` immediately (or as soon as possible):
>
> try {
> thing1.shutdown(); // throws InterruptedException
> process2.close(); // does not throw InterruptedException
> thing3.shutdown(); // throws InterruptedException
> } catch (InterruptedException e) {
> // bail out now
> }
I'm a bit dubious about the code above because it does not appear to fully
handle the InterruptedException.
If it is really shutting down then its just complicit in leaving the
application is an unpredictable and probably unrecoverable state.
Propagating the checked exception reduces the usability of close() to the point
that I would remove the waitFor.
It annoying enough already that `waitFor` throws InterruptedException and you
have to write more code and maybe a loop to handle that interruption and what
it means to the caller.
I would leave up to the caller to handle that case.
When used with try-with-resources, the exception handling/re-throwing is
complicated enough.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2255342872
