Hi Martin,
The choice of UnsupportedOperationException specifies a complete inability
of the runtime to ever launch a Process. IOException on the other hand
is appropriate in cases where there are configuration or OS implementation
dependencies or transient behavior.
Existing applications that expect to spawn processes are very unlikely to be
appropriate for a target platform without Process support. For new and
retargeted applications identifying such a basic mismatch should be
immediate and conclusive.
Adding a subtype of IOException doesn't help existing applications and
adds to the already overloaded IOException.
It seems more valuable to make a clear distinction in the specification
than to add to the current vagaries of OS dependencies.
Roger
On 2/1/15 3:18 PM, Martin Buchholz wrote:
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 <marti...@google.com
<mailto:marti...@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.bate...@oracle.com <mailto:alan.bate...@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
