code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile

Alan Bateman Alan.Bateman at
Wed Nov 2 06:35:44 UTC 2011

On 01/11/2011 09:47, Seán Coffey wrote:
> :
> Are you referring to the parent.close() call ? If otherParents is 
> null, then we only have one reference to this FileDesriptor - i.e the 
> Stream that has called close().
It's parent.close() that I'm wondering about. Suppose p1 is the parent, 
p2 is in otherParents. If p2.close is invoked then it looks like p1's 
close method will not be invoked, leaving p1 open and the underlying 
file descriptor closed.

> Any exception from releaser.close() becomes the main exception if one 
> is seen there. Any exceptions from the earlier closes are then added 
> as suppressed. I've run some tests on this and it looked to work as 
> expected. (stack trace below)
In this example then the IOException appears to be thrown suppressing 
one exception. That suppression exception in turn suppresses two others. 
I had expected that the primary IOException would have suppressed three 
exceptions. As I said, in practical terms this is much of a concern, 
just pointing out that it's not exactly as expected.

> I used hg rm/add. I guess hg mv would have worked too.
You need to use hg mv so that the history can be followed. Also webrev 
handles it, at least before you create the changeset, so that you can 
easily see the changes.


More information about the core-libs-dev mailing list