Re: different try-finally approach
Pitch wrote:
In article <h588io$aq6$1@news.albasani.net>, noone@lewscanon.com
says...>
Pitch wrote:
In both situations constructor is allowed to fail. But in "java [sic] way" [sic] if
constructor fails, the close() statement is never called, so it's pretty
much the same thing, right?
Neither way is a particularly "Java" way.
I guess the bottom line is wheather you'll use internal catch or an
external one. I prefer the external ones, or even dividing the code
between methods.
I prefer:
public void doSomething()
// throws [MyResource|App]Exception
{
final MyResource res;
try
{
res = new MyResource();
}
catch ( MyResourceException exc )
{
logger.error( exc );
return; // or throw exc or new AppException(exc)
}
assert res != null;
try
{
// do something with res
}
finally
{
res.close()
}
}
This implies res is not going to get null in the last try-block. I think
this is a real possibility if more programmers work on the code so you'd
still need if != null
No, 'res' is guaranteed not to be null.
--
Lew