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

Martin Buchholz martinrb at google.com
Fri Feb 20 21:06:05 UTC 2015


I totally disagree about "recoverable condition".  Instead of thinking
about "recovering", think instead about whether it ever makes sense to
catch the resulting exception.  See my sample code broken by the switch to
UOE.

On Fri, Feb 20, 2015 at 11:58 AM, Roger Riggs <Roger.Riggs at oracle.com>
wrote:

> Hi Martin,
>
> As I said earlier, launching a Process when process is not implemented
> is not a recoverable condition; there are no conditions under which it will
> succeed.  If the application is probing to determine what
> is supported on a platform then it should be prepared to handle UOE
> or using a test for the specific capability it requires.
>
> Roger
>
>
>
> On 2/20/2015 1:34 PM, Martin Buchholz wrote:
>
>> One reason I keep pouring salt on this tiny wound is that throwing
>> (unchecked) UOE for system-dependent failures when normally IOE is thrown
>> is a fundamental design mistake for java and its checked exception design.
>> I think it violates Josh's Effective Java Item 58: Use checked exceptions
>> for recoverable conditions and runtime exceptions for programming errors.
>> I don't think it's worth fixing places in jdk8 where this small mistake
>> was
>> made, but we can at least stop the incompatible worsening of existing
>> APIs.
>>
>> On Fri, Feb 20, 2015 at 3:49 AM, Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>
>>  On 19/02/2015 21:54, Jason Mehrens wrote:
>>>
>>>  I'm assuming that compatibility is given more weight vs. correcting
>>>> choices made in the original design.
>>>>
>>>>   Yes, I think we've spent more than enough time on it. In this case
>>>> it's
>>>>
>>> for a major release only and the compatibility impact seems to be only
>>> platforms or implementations that don't support launching of processes
>>> today but are running applications that attempt to start processes
>>> anyway.
>>> So overall it doesn't seem to be something to be overly concerned with.
>>>
>>> -Alan
>>>
>>>
>



More information about the core-libs-dev mailing list