Roger et al, Whichever way we go doesn't matter much. But I continue to think that IOE is a better choice than UOE and I have trouble seeing the motivation for the change to use UOE. If you wanted to provide a way to tell if subprocess support was available at all, then it would be better to add a new static boolean method to Process (but I wouldn't support that either). But (Roger and Alan): feel free to outvote me.
On Wed, Feb 11, 2015 at 12:24 PM, Roger Riggs <roger.ri...@oracle.com> wrote: > 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 >> >> >> >
