Hi Martin,
I'm still looking for additional support for using IOException instead of
UnsupportedOperationException; the prevailing view is that UOE is
appropriate.
The usual definition of UnsupportedOperationException seem to fit this
case well.
The behavior of the methods is not supported by the implementation; it
is unconditional,
it is not a question of OS policy or Java runtime policy.
The examples cited avoid using Process if the OS dependent programs are not
available and in those cases the UOE would not be encountered so this should
not raise issues for existing programs.
Roger
On 2/3/15 2:30 PM, Martin Buchholz wrote:
I agree that we should not be throwing SecurityException. We should be
throwing IOException.
But given a choice between SecurityException and
UnsupportedOperationException, I would regard the former as the lesser
of two evils.
On Tue, Feb 3, 2015 at 12:40 AM, Alan Bateman <alan.bate...@oracle.com
<mailto:alan.bate...@oracle.com>> wrote:
On 02/02/2015 21:06, Martin Buchholz wrote:
:
The historic spec allows for both SecurityException and
IOException (but
not UOE).
Locked-down systems typically (but not necessarily) have a
SecurityManager
that helps enforce the restrictions and so SecurityException
seems vaguely
appropriate.
There are a small number of places where SecurityException is
thrown when not running with a security manager (defineClass,
package sealing) but it can be confusing for developers to get
this exception when there isn't a Java security manager. So I
don't think we should be using it here.
-Alan
