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_mehr...@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: marti...@google.com > > To: roger.ri...@oracle.com > > CC: core-libs-dev@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.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 > >>>> > >>>> > >> >