On 02/11/2011 06:35, Alan Bateman wrote:
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.
The parent gets added to the ArrayList when that ArrayList needs to be
set up (more than 1 referent) so this shouldn't be a problem. When the
ArrayList (otherParents) is non-null a close will be called on the
stream that initiated the close operation (through recursion) - that
should be a no-op at that stage though. (closed == true)
regards,
Sean.
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.
-Alan.
