>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> 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 > > > >