Frank,
What should probably happen is that the FileObject.close() should be
called first, this then gives you the opportunity to close the stream
and handle the errors. The outStream close() would be called anyway,
because not everyone may want to handle their own close() so it insures
the stream is closed.
In the STOR command
...
finally {
// provide an opportunity for the FileObject to handle close
IoUtils.close(file);
// close the stream, it may have been previously closed, make sure
IoUtils.close(outStream);
}
In the FileObject
public void close() {
// close the stream(s) or raf
// do some other clean-up
}
This implies some changes in the FileObject issuance of the
createOutputStream() and createInputStream() if you wish to handle the
close on the stream(s). Or at least a change for the write-stream in any
case.
Once an operation [close() for example] leaves the FileObject, ie, it's
at the Command-level, the command-level does not know one file object
from another, nor if one FileObject is suppose to be handled
differently, it's just doing an assembly-line operation.
Does the above make sense on why a FileObject.close() was proposed?
Trying to handle individual FileObject tasks at the command level just
causes the "assembly-line" to slow down, and possibly break. Far better
to call the FileObject and let it deal with it's needs.
From your comments [excellent feedback], what should be done at the
command-level is call the FileObject.close() first, then the stream close.
Andy Thomson
Frank van der Kleij wrote:
Thanks for commenting on the issue.
The close on the file object seems a good idea in general but for me it won't
do the trick. The Apache VFS API does provide for close operations but they
serve a slightly different purpose.
VFS uses a stream based API to write; three objects are involved, a FileObject,
a FileContent and an OutputStream ( to write you'd have to do
fileObject.getFileContent().getOutputStream() ). Close on FileObject means
you're done treating the file, which is different from meaning that you're done
writing to it. The same goes for close on FileContent, which is supposed to
release all resources and closes InputStreams as well. Only close on the
OutputStream only means that all data is transferred.
For information, internally in VFS operations, e.g. on a copy operation, the close is only called on the outputstream too.
My point is that a close on the FileObject is not what I'm looking for; it is rather the handling of exceptions on close of the stream that concern me.
I doubt it is really necessary to ignore exceptions on the close of the stream.
I can imagine it was done because the close is called in a finally block and
handling exceptions there is rather ugly.
By doing the close before the finally the exceptions can be handled normally.
It would do a double close on the same stream, but streams are supposed to
support that kind of thing.
Best regards,
Frank
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
