This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | StreamPool.NotifyOutputStream doesn't close on exception in wrapped output stream | ||
---|---|---|---|
Product: | platform | Reporter: | jsmith5and5 |
Component: | Filesystems | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | 7.0 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
jsmith5and5
2011-04-06 18:42:45 UTC
Can we assume the file is closed when wrapped close() throws an exception? That sounds like a philosophical question. ergonomics#d87620969501 Right. In general I don't think you can assume an OutputStream is closed if an exception is thrown. Unfortunately the java.io.OutputStream.close doesn't explicitly say that the contract is nullified if an IOException is thrown but I think this is to be assumed. It's reasonable to have an OutputStream which fails once to close due to a "brief" (brief being anything longer than the timeout in close) communication outage but that is able to successfully close the next try (I know most people don't code to this level of robustness, but that's another thing). However, I would say for these purposes that you can assume the outputstream is "closed". As I understand the NetBeans Platform code around this (which I've only looked at briefly) is trying to be extra helpful by not writing to resources which perhaps are already being read from or written to. This is nice for it to do but ultimately it is really the job of the wrapped OutputStream to check this. In other words, I saw it as nice-to-have code that protects bad implementations from themselves. Let's say the NPB code assumed the wrapped outputstream was closed even if it wasn't. I know that at least in the case of my implementation of filesystem (and in the case of writing to the OS filesystem because of the locks it keeps, etc.) that if a previous inputstream or outputstream to a file was currently in use, then the new outputstream would fail with an exception at least by the time of the call to read/write (if that was desired). Sorry if that's a little long-winded. Just wanted to be clear about it. Appendix: Javadoc for java.io.OutputStream.close close public void close() throws IOException Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. The close method of OutputStream does nothing. Specified by: close in interface Closeable Throws: IOException - if an I/O error occurs. Integrated into 'main-golden', will be available in build *201104150401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/d87620969501 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #197504: Release the mutual exclusion lock when close is attempted, not only successfully finished |