commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [imaging] Closing stream
Date Fri, 25 Oct 2013 14:21:14 GMT
Thanks, Sebastian, but I don't see how the discussion there relates to the
"custom Java compiler" alternative postulated by Damjan, which is what I
was responding to.  Which is not to say it doesn't relate; I may be being
thick.

Matt


On Fri, Oct 25, 2013 at 8:50 AM, sebb <sebbaz@gmail.com> wrote:

> There was some related discussion here:
>
> https://issues.apache.org/jira/browse/IO-249
>
> On 25 October 2013 12:52, Matt Benson <gudnabrsam@gmail.com> wrote:
> > On Oct 25, 2013 6:30 AM, "Damjan Jovanovic" <damjan.jov@gmail.com>
> wrote:
> >>
> >> On Fri, Oct 25, 2013 at 12:36 PM, Jörg Schaible
> >> <Joerg.Schaible@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.
> >>
> >> 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.
> >>
> >
> > I haven't deeply followed this conversation, but would this be a
> candidate
> > for a [weaver] module?
> >
> > Matt
> >
> >> Damjan
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message