Re: (File)OutputStreams and their usage
On Fri, 16 May 2008, Leonard Milcin wrote:
Philipp wrote:
Leonard Milcin wrote:
Philipp wrote:
Is this (see code) the correct way of handling a FileOutputStream?
Specific question are in the code. Thanks for your answers.
Well, you're converting from exceptions to error codes. load() can
silently fail and it's up to the caller to check if it has loaded
anything. I would propagate exceptions or convert them to another type of
exception.
Yes, you are correct, I should definitely rethrow rather than log at
that point. But this was not really my question. I'm rather asking at
what points I I have to call close() on the stream to gurantee correct
release of resources in all cases and whether having a return in the
first or second catch is problematic in this respect.
public void load(File file) throws ... {
OutputStream os;
try {
os = new FileOutputStream(file);
load(os);
} finally {
if (os!=null) {
os.close();
}
}
}
That looks much cleaner.
It does. But it doesn't compile.
Something everyone has missed here - god alone knows how, since it's
pretty bloody basic - is that if the initialisation of a variable fails
due to an exception, then that variable is uninitialised, and it can't be
used. Plus, if you're somewhere where there's a chance that a variable
might be uninitialised, you aren't allowed to use it.
That means that your finally clause is illegal - it could be reached
following an exception in "new FileOutputStream(file)", and so the
variable os has to be treated as potentially uninitialised, and so
unusable.
Philipp's original code had this situation too - where he asks "can os be
non-null here? should I put a close() here?". The answer is that os can't
be non-null, and it also can't be null - it's uninitialized. So it's not
so much that you don't need to check for a non-null os, or close it, as
much as that you can't.
So to finally address what i think Philipp is asking: you can't clean up a
failed FileOutputStream, but happily, you don't need to: it's the
constructor's job to clean up after itself before throwing an exception.
Hopefully, it's actually doing this.
In Leonard's code, there's a simple fix: change the declaration of os to
be an initialisation:
OutputStream os = null ;
Then everything works as it should.
I'm dubious about the close() in the finally block not being wrapped in a
try-catch; if i get an IO error during loading, i want to see that, not
some subsequent exception that arose when trying to close the file. I'd
wrap it in a try-catch and log or ignore any exceptions.
There's actually a yet slicker way to write this method:
public void load(File file) throws IOException {
OutputStream os = new FileOutputStream(file) ;
try {
load(os) ;
}
finally {
try {
os.close() ;
}
catch (IOException e) {
// log or ignore
}
}
}
You put the FileOutputStream constructor outside the try-finally block;
you know that if it fails, there's no stream to close, so there's no
reason to have it inside. That means you can drop the test for null.
The caller has to deal with all those checked excetions, though. You can
convert to another type of exception
Yes.
(like unchecked exception).
NO!
The reason why I don't surround os.close() with try/catch is that
usually it should not throw exception but if it does... I would
certainly want to know.
Very sound advice.
To answer Philipp's other question, the return in your second catch block
is pointless. With or without it, execution will go through the finally
block and then leave the method.
I'll add a question of my own: why are we loading from an *output* stream?
tom
--
It's the 21st century, man - we rue _minutes_. -- Benjamin Rosenbaum