Re: different try-finally approach
Pitch wrote:
In java [sic] it is common to check if the resource is null in finally
statement, before closing it:
public void doSomething() throws MyResourceException
{
MyResource res = null;
try
{
res = new MyResource();
// do something
}
finally
{
if (res != null) res.close()
}
}
Ugly.
But in some other languages this is the preferred way:
public void doSomething() throws MyResourceException
{
MyResource res = new MyResource();
try
{
// do something
}
finally
{
res.close()
}
}
This is also doable in Java.
The first example ensures nothing more than the second one, right? If
I suppose, but it is different.
the constructor throws an exception the "res" is null, so it can't be
closed anyways.
So, my question is - why the extra coding in java [sic]? Am I missing
something?
Both examples you show are valid in Java.
I prefer neither one. I eliminate the redundant assignment to 'null' and use
try-catch on the resource allocation, with a followup assertion, then a
separate try-finally on the resource usage.
Tom Anderson wrote:
I'm not aware that the former is 'preferred' in java [sic]. I certainly
strongly prefer the latter. Indeed, i [sic] consider the former an error, and
i'll [sic] fix it when i [sic] see it in code.
I'm with tom, except I don't like merely rethrowing exceptions as the second
example shows. It is better to catch, log and handle the exception
immediately. If there's a rethrow, it'll be to a higher-level exception.
I prefer to put the resource allocation in a try-catch with return on failure,
and the resource usage in a separate try-catch-finally, with an assertion
between them that the resource pointer is not null.
There is no "extra" coding in any of the three alternatives. Resource
allocation must be guarded against failure; code that deals with potential
failure is not "extra". However, one could regard the assignment to 'null' as
superfluous if one takes the view that a failed resource allocation should
result in no assignment whatsoever to the resource pointer.
--
Lew