BufferedWriter.write does not throw exception if it is already closed. (original) (raw)

Jing LV lvjing at linux.vnet.ibm.com
Fri Jan 28 14:50:51 UTC 2011

Thanks for reply Alan, sorry didn't see this mail before I raise an issue on https://bugs.openjdk.java.net/show_bug.cgi?id=100169 (my mail server seems some problem these days)

Consider it is using underlying writer, one thing I need to mention is that in the testcase I post in the first mail, it was trying to throw an exception[1] in its write method when it's closed already. I am ok with the documentation modification myself, however I wonder it may confuse customer if he found his own writer has no problem at all?

[1] @Override public void write(char[] buf, int offset, int count) throws IOException { if (closed) { throw new IOException("Already closed"); } }

于 2011-1-28 18:55, Alan Bateman 写道:

Jing LV wrote:

Hi Alan,

(Sorry for late reply that it seems my mail-box has some trouble that I cannot send my mail yesterday). I agreed with you that the document may be changed. However as you see another problem is that the write method is unstable, it may or may not throw the exception, only depends on its buffer size, I think we'd better at least fix this unpredictable behaviour? I think this is part of the same issue. BufferedWriter#close is failing because the underlying Writer's close is failing. This leaves the BufferedWriter "open" and the underlying Writer "closed". If you continue writing then the BufferedWriter may continue to buffer characters but if it has to flush to the underlying Writer then it will fail. This is clearly undesirable and it may be best to clarify the spec so that stream will be considered to be closed even if the close fails (as the current behavior is long standing behavior we would just need to think through any implications/side-effects). We can easily the implementation too, and in addition the suppressed exception support gives us the opportunity to fix a few other issues in these classes. I'll create a bug for this today. -Alan.

More information about the core-libs-dev mailing list