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.ri...@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.bate...@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 >>> >>> >
