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

[Martin Buchholz]

I'm not sure I'm convincing anyone other than myself, but here's another
try:

"recover" means taking any action at all, the most common of which is ...
nothing!
Perhaps a product feature simply becomes "grayed out" when running a
process fails.
>From a WORA developer's point of view, it is irrelevant whether failure is
due to complete lack of subprocess support or a "real" IOException.  So I
don't think UOE is ever suitable for these sorts of failures (not just
Process).  But for Process we're making the API worse _AND_ breaking
existing programs.

Here's a more elaborate explanation around Josh's Item 58:
http://stackoverflow.com/questions/3540613/please-explain-runtimeexception-in-java-and-where-it-should-be-used/3540705#3540705


On Sat, Feb 21, 2015 at 2:03 PM, Jason Mehrens <jason_mehrens at hotmail.com>
wrote:

> Hi Roger,
>
> For what it is worth, the most common production use case for me is:
>
> 1. Generate output from some source to a temp file.
> 2. Use ProcessBuilder to launch process (native or JVM) for using temp
> file.
> 3. If that fails with IOException fallback to opening a save dialog.
> 4. The end user will use #2 or #3 to save the file to a known location.
> 5. The end user will finish final product or get it to a machine that
> works then finish the final product.
> 6. (non)Profit.
>
>
> So in this case you wait around for #1 to get done and as long as #2 or #3
> work then #1 wasn't a wasted effort. In the UOE case 3 through 6 are
> skipped which is a bad deal for the end user.  This is 15+ years still in
> production code where the steps were crafted by a natural evolution of the
> Murphy's Law based environment that it exists in.  End of life for this
> code is not in sight.
>
>
> Save your health and don't think too hard about the example, try to apply
> logic to it, or tear it down.  It is not my intent to hold this example up
> as 'the best counter argument', 'sky is falling' or to drag this thread
> out.  The point is, no where in the example does the calling code or user
> care about the distinction between never being able to create a process or
> creating a process failed this time.  For this code, throwing UOE is a
> breaking feature not a bug fix.  The only known thing was the API
> contract.  Everything else was assumed to be broken.
>
>
> I do appreciate your time, Alan's time, the time you have spent on this
> issue, and your arguments as they are logical.  We just differ on applying
> the logic to this case.  I also understand the decision has been made and
> that will be the future.  I'll just have to be prepared for it and Murphy.
>
>
> Respectfully,
>
>
> Jason
>
>
> ----------------------------------------
> > Date: Fri, 20 Feb 2015 13:06:05 -0800
> > Subject: Re: RFR 9 8055330: (process spec) ProcessBuilder.start and
> Runtime.exec should throw UnsupportedOperationException ...
> > From: martinrb at google.com
> > To: Roger.Riggs at oracle.com
> > CC: core-libs-dev at openjdk.java.net
> >
> > 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
> >>>>
> >>>>
> >>
>