The check for os non-nullity is not needed here.  Because of that, you can
move the close() inside the try{} block.  This helps, too, because close() can
throw an Exception, too.

The idiom above is a bit too loose.  It doesn't log, it doesn't translate the
Exception into the application domain, and it allows Exceptions to happen in
the finally{} block.  It also doesn't admit of a coherent Exception-handling
strategy throughout the application.

Catch-log-and-rethrow is a better idiom, or declare a return type that can
indicate failure if client code cares not for the reason.

Catch-log-and-rethrow puts the condition into application-specific terms.  One
would create an application-specific Exception subtype, or a hierarchy of them.

try
{
  OutputStream os = new FileOutputStream(file);
  workWithGuaranteedNonNullValue( os );
  // factored method that handles its own exceptions
  os.close();
}
catch ( IOException exc )
{
  logger.error( IOERROR_MSG, exc );
}

It is easy to add a return value, with success from the try{} or failure from
the catch{}.

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.

Yes.

NO!

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