FilterOutputStream.close() throws exception from flush()

Bernd ecki at
Mon May 5 09:44:49 UTC 2014

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 place.

Am 05.05.2014 11:32 schrieb "Alan Bateman" <Alan.Bateman at>:

> 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 generally a very good improvement (and I am glad that
>> thereby got fixed).
>> However the implementation with the try-with-resource has a problem:
>> when flush() and close() report the same exception instance the
>> construction of the suppressed exception will actually fail with an
>> IllegalArgumentException.
>> This IllegalArgumentException of Throwable.addSuppressed is very
>> unfortunate (it would be better simply ignore it).
>> Anyway, this new behavior broke a Unit-Test for Apache VFS as you can
>> see here:
>> I think this can only be fixed in Throwable by avoiding this
>> IllegalArgumentException or by the close() method not using
>> try-with-resource.
>> For reference, according to this changeset other locations are affected
>> as well:
>>  Thanks this bug report, I've created JDK-8042377 to track it. I don't
> think this has come up before, probably because flush and close are more
> likely to throw new exceptions rather than equal (cached) exceptions.
> I don't see this issue as driver to changing Throwable to support self
> suppression but we can change BufferedWriter and FilteredOuputStream to
> only add the suppressed exception when they are not equal.
> -Alan.

More information about the core-libs-dev mailing list