7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails
Rémi Forax
forax at univ-mlv.fr
Tue Aug 9 13:10:26 UTC 2011
On 08/09/2011 01:43 PM, Alan Bateman wrote:
>
> A few months back there was a bug report [1] pointing out that it's
> possible to continue writing to a BufferedWriter after invoking its
> close method and the close fails. A similar issue arises with
> BufferedOutputStream and other classes. At issue is whether a stream
> (or more generally a resource) is considered closed in the event that
> the close method fails. This isn't something that Closeable is clear
> on. Joe tells me that this didn't come up in the Coin discussions on
> try-with-resources either.
>
> I think it's safe to say that it would be desirable that close
> releases the resources for failing cases as otherwise the resources
> may never be released (esp. with try-with-resources usages).
> Furthermore, when there are multiple resources involved, or cases like
> the bug report where one stream wraps another, then it would be
> desirable to keep the state of the resources in sync. To that end, the
> changes here propose adding an advisory note to AutoCloseable to
> advise implementers to release the underlying resources and to mark
> the resource as closed prior to throwing the exception.
>
> For the specific buffering classes discussed at the time, these are
> changed to follow this advise (but their javadoc isn't changed as
> there may be other implementations or these classes extended in many
> ways). In the case of BufferedWriter it is also fixed so that any
> exception from flushing the underlying writer isn't supplanted by the
> exception from close. In the case of FilterOutputStream
> (BufferedOutputStream extends it) then it is fixed so that it doesn't
> ignore the exception thrown when flushing the underlying stream. This
> is clearly the right thing to do but it does mean that close can now
> throw an IOException for a case where it didn't before. For now I
> don't propose to include a compatibility switch but this may be
> something that has to revisited later. There are other classes in
> java.io that could also be cleaned up but I don't propose to do a
> complete audit at this time.
>
> The webrev with the changes is here:
> http://cr.openjdk.java.net/~alanb/7015589/webrev/
>
> Thanks,
> Alan.
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005732.html
Let's close() close :)
Patch looks good.
Rémi
More information about the core-libs-dev
mailing list