RFR 9 8055330: (process spec) ProcessBuilder.start and Runtime.exec should throw UnsupportedOperationException ...

[Martin Buchholz]

More generally, it seems like an API design mistake (for the Java language
with its controversial checked exceptions) to throw UOE instead of IOE for
any operation that interacts with the environment external to the JVM.

What is the benefit for users?

On Sat, Jan 31, 2015 at 1:30 PM, Martin Buchholz <martinrb at google.com>
wrote:

> From a tck point of view, Process has always seems untestable, since any
> process creation can fail at any time for any (external) reason.  Adding
> special handling for OSes where a Process can never be created doesn't
> help... please explain.
>
> My feeling that we should consistently fail with IOException is
> hardening.  It's reasonable to throw a subclass that explains that you're
> on an OS where no subprocesses are allowed, or you can only start
> subprocesses after 7pm, or the only command you can run is { "cthulu" }.
>
> On Sat, Jan 31, 2015 at 1:03 PM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 31/01/2015 16:15, Martin Buchholz wrote:
>>
>>> It's not a big deal, but I am opposed to this change.
>>>
>> Just an FYI that Roger seems to have pushed the original patch, this new
>> patch just moves the text down so that it flows a bit better.
>>
>>  The old spec
>>>
>>>      * <p>In such cases an exception will be thrown. The exact nature
>>>      * of the exception is system-dependent, but it will always be a
>>>      * subclass of {@link IOException}.
>>>
>>> is perfectly adequate for OSes with no subprocesses.
>>> Users should be catching and handling IOException in any case.  Throwing
>>> a RuntimeException seems wrong, and breaks the above promise!
>>>
>>>  It's lack of clarity in the above text that has been causing the
>> testability issue for so long so I think it is good to make it clear how an
>> implementation that does not support processes should behave. The options
>> on the table seem to be to define a sub-type of IOE for this case, specify
>> that an IOE be thrown with an UOE as the cause, or just throw UOE when this
>> feature is not supported.
>>
>> -Alan
>>
>>
>>
>>
>