On 1/5/07, Stephane Bailliez <[EMAIL PROTECTED]> wrote:
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()
}
You're right, it would be cleaner like this. It would avoid swalloling the
original exception by the exception in the close if any.
Xavier
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
