Re: what's the point in finally?
Daniel Pitts wrote:
One typical use case:
try {
return parseSomeXml();
} catch (ParserException e) {
throw new MyGenericException("Can parse xml", e);
} catch (IOException e) {
throw new MyGenericException("IO problem loading XML", e);
} finally {
cleanUpStuff();
}
The trouble is that cleanUpStuff is usually declared to throw an
exception. Therefore code like that is often incorrect or messy.
My guess is that the evolution of Java went something like:
o Start with C++ where resources are flushed explicitly and destructor
do not throw. If you throw an exception from a destructor and the
destructor is called due to an exception unwinding the stack then, IIRC,
abort is called which by default calls terminate.
o This makes try-catch-finally relatively natural. I believe catch
(...) logically comes after catches with explicit exception types in
C++. I guess catch-before-finally can also allow the exception object to
depend upon the resource still being open (though generally a poor idea).
o Java goes in for virtual methods and decorators. Unfortunately
"ownership" of the resource is moved into the decorator (this would make
sense if the "decorator" create the resource from a factory rather than
being passed through the constructor).
o In order to support such decorators (buffered output streams for
example), all resources can throw exceptions when being closed. Closing
an input stream is a classic example where a close declares that it
throws an exception, but probably shouldn't.
o We are now in a situation where finally needs to be inside the try
block, but the syntax is the wrong way around.
There is also the problem that the finally block will need a reference
to the resource, even though the construction of the resource needs to
be within the try-catch.
So the general pattern should be:
try {
acquire-resource;
try {
decorate-resource;
use-decorator;
flush-decorator;
} finally {
release-resource;
}
} catch (ResourceException exc) {
... erm, do something sensible ...
... probably wrap in a different exception ...
}
Now, if the exception makes sense for the method to throw, the catch can
be removed.
With closures, such as methods within anonymous inner classes, the
common code can be factored out (although with the current syntax, you
will still end up with some highly verbose boilerplate).
Tom Hawtin