Xavier Hanin wrote:
Now for the FileUtil and CopyProgressListener part, the documentation
doesn't say anything, but I think that the intent is to send an event
only
if the transfer is successfully completed. Maybe adding an event in
case of
an error would improve the API, and then to avoid modifying the
CopyProgressListener interface we could simply call end and add an
exception
in the CopyProgressEvent. But if we want to call the end method only
if the
copy is actually successful, putting the call after closing the streams
would cause it to be sent if an exception occured in the try block. So we
No don't put the end() in the finally. what I meant was :
try {
copy(...)
} finally {
close()
}
end()
That is, end() is only called if it is successful. which looks like to
me the original intent.
end() cannot really be before the close() as the close() does an
underlying flush()/close().
So considering it is silly to throw an exception in the finally when you
may already have an exception, maybe do
try {
copy(...)
close()
} finally {
closequietly()
}
should remind to test if we have actually reached the end of the try
block
before calling the end method. Or test if no exception was raised,
which is
better if we want to call the end method in all cases, with an
exception in
case of a transfer which caused an exception, and without in case of a
successful transfer.
What do you think?
have to read that piece of code again. busy for the day now. :)
-- stephane
