Hello,
sorry for coming up with that thread again, but I see that JDK-8042377
is hanging around with no action, and there was not yet any discussion
I have seen about why it would be robust to call this IAE.
I know there was quite some work done in 2013 to make this
self-supression IAE a bit
On 03/05/2014 01:04, Bernd Eckenfels wrote:
Hello,
back in 2011 there was a discussion about the new changed behavior of
FilterOutputStream (and BufferedOutputStream) in regards to not anymore
swalloging IOExceptions from flush() on this list (thats where I got
the subject from).
This was
Thanks Alan,
I just want to add that I think the IAE is quite in a unfortunate location
when it is caused by TWR. Especially for that usecase silently ignoring the
add is more robust.
If you look at Stackoverflow or Google there ard already other People
confused by it, it happens all over the
On 05/05/2014 11:31 AM, Alan Bateman wrote:
On 03/05/2014 01:04, Bernd Eckenfels wrote:
Hello,
back in 2011 there was a discussion about the new changed behavior of
FilterOutputStream (and BufferedOutputStream) in regards to not anymore
swalloging IOExceptions from flush() on this list (thats
On 05/05/2014 15:40, Peter Levart wrote:
Hi Alan,
There has been a discussion about a year ago on this list:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015947.html
Yes, I remember this and also reviewed it for Joe. My point about it not
coming up before was in the
Hello,
back in 2011 there was a discussion about the new changed behavior of
FilterOutputStream (and BufferedOutputStream) in regards to not anymore
swalloging IOExceptions from flush() on this list (thats where I got
the subject from).
This was generally a very good improvement (and I am glad
Hi there,
I have some code which calls FilterOutputStream.close(), which calls
the underlying OutputStream.flush() which throws IOException.
With previous versions of JavaSE, close() returns successfully without
any problems.
Using JDK8-b24, I get an IOException which is propagated from
I think I have narrowed it down to this changeset:
http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/759aa847dcaf
7015589: (spec) BufferedWriter.close leaves stream open if close of
underlying Writer fails
Which no longer catches and ignores the exception thrown by flush():
try (OutputStream
Hi there,
Thanks for the pointer - I wasn't able to trace back to that email for
some reasons.
The problem is that:
- flush() is reporting IOException because underlying stream is closed
- close() is then forwarding that IOException now in JavaSE 8
I guess my question is: what is the best
On 10/02/2012 13:52, Alex Lam S.L. wrote:
Hi there,
Thanks for the pointer - I wasn't able to trace back to that email for
some reasons.
The problem is that:
- flush() is reporting IOException because underlying stream is closed
- close() is then forwarding that IOException now in JavaSE
On 02/10/2012 02:52 PM, Alex Lam S.L. wrote:
Hi there,
Thanks for the pointer - I wasn't able to trace back to that email for
some reasons.
The problem is that:
- flush() is reporting IOException because underlying stream is closed
- close() is then forwarding that IOException now in
It is a custom OutputStream class which is not part of the JDK.
In this case close() is being called multiple times, because there are
actions which relies it. And flush() will throw IOException if the
stream is already closed.
I guess I can work around this by introducing a boolean flag to
On 10/02/2012 13:16, Alex Lam S.L. wrote:
To recover the previous behaviour, I think the following might just work:
try (OutputStream ostream = out) {
flush();
} catch (IOException ignored) {
}
Remember try-with-resource-catch works the inside-out from
try-catch-finally! You are
It sounds very reasonable when you put it that way ;-)
I was thinking along the lines of when flush() fails - clearly you
can't flush a stream when it is closed - then it should throw an
IOException. =
Either way - I will sleep some more on my code and work around this in JDK8.
Thank you and
14 matches
Mail list logo
