an On Fri, Oct 25, 2013 at 5:24 PM, Jörg Schaible <joerg.schai...@gmx.de> wrote: > Hi Damjan, > > Damjan Jovanovic wrote: > >> On Fri, Oct 25, 2013 at 12:36 PM, Jörg Schaible >> <joerg.schai...@scalaris.com> wrote: >>> Hi Damjan, >>> >>> Damjan Jovanovic wrote: >>> >>> [snip] >>> >>> Thanks for explanation. >>> >>>> We would be able to adapt that for Java < 1.7 by swallowing the close >>>> exception instead of calling addSuppressed() on the primary exception, >>>> but the show stopper is catching and rethrowing the primary exception >>>> (Throwable), which javac < 1.7 refuses to compile because it doesn't >>>> do "Rethrowing Exceptions with More Inclusive Type Checking" >>>> (http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html). >>>> >>>> But this would work and always sets succeeded correctly without >>>> catch/re-throw: >>>> >>>> final InputStream is = factoryMethodThatCanThrow(); >>>> boolean succeeded = false; >>>> try { >>>> try { >>>> is.methodThatCanThrow(); >>>> } finally { >>>> } >>>> succeeded = true; >>>> } finally { >>>> closeSafely(!succeeded, is); >>>> } >>> >>> I guess the nested try was unintentionally ;-) >>> >>> Cheers, >>> Jörg >> >> Well that actually won't work, because the "succeeded = true;" will be >> skipped if there is a "return;" in the inner try. > > Well, but this has to be done in our code, so we can either change it or set > "succedded = true" before the return as well. > > To mimic Java 7, we could also implement: > > ============= %< =============== > Throwable t = null; > try { > } (catch IOException e) { t = e; throw e; } > // ... another line for each checked exception > } (catch RuntimeException e) { t = e; throw e; } > } (catch Error e) { t = e; throw e; } > } finally { > closeSafely(t != null, is); > } > ============= %< =============== > > but as commented, we have to add a catch for every checked exception, > anotehr one for RuntimeException and one for Error. The approach with the > succeeded flag seems easier ... > >> Other than a custom Java compiler, I guess there's no clean way of >> doing this in Java < 1.7. There's really only option 2 - with being >> careful to always set succeeded correctly on all paths out of the try >> block. Almost like releasing memory in C. > > Yep. > > Cheers, > Jörg >
One thing that amuses me to no end, is that while it's at least a solved problem in Java 7, exceptions thrown from C#'s Dispose() method in a using() block always swallow the original exception, just like an uncaught close() exception in Java's finally :) (http://blogs.infosupport.com/the-c-using-statement-and-suppressed-exceptions-compared-to-java-7-try-with/). Anyway I now think the way forward is Java 7. Java 5 was EOL since 3 November 2009, and Java 6 was EOL since February 2013 (with a last update on 6 March 2013). There are ways of getting Java 7 features like try-with-resources on Android (https://github.com/yareally/Java7-on-Android) and besides Imaging's use of java.awt.* packages is a bigger barrier there. Applications and JVMs will eventually support Java 7 anyway, and even if they don't, a special compiler could produce binaries for earlier versions of Java. Can I just go change the POM to Java 7 or do we need a vote? Damjan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
