My Preferred try...finally Semantic

Carrying on a JDBC motif from my previous entry, I want to talk about the use of try...finally blocks in managing resources.

All too often I see null-checking used in finally blocks because this kind of construct is used:

Connection conn = null;
try
{
    conn = ds.getConnection();
    //do some work with the connection.
    ...
}
catch(SQLException sqle)
{
    LOG.error(sqle);
}
finally
{
    if(conn!=null)
    {
        try
        {
            conn.close();
        }
        catch(SQLException sqle)
        {
            LOG.error(sqle);
        }
    }
}

I personally prefer this kind of construct which eliminates the null check at the expense of adding another try..catch block:

try
{
    Connection conn = ds.getConnection();
    try
    {
        //do some work with the connection.
        ...
    }
    finally
    {
        try
        {
            conn.close();
        }
        catch(SQLException sqle)
        {
            LOG.error(sqle);
        }
    }
}
catch(SQLException sqle)
{
    LOG.error(sqle);
}

This is purely stylistic, but I prefer not to have the null check and I do like having the exceptions all towards the end of the unit of code. Do not be tempted to remove the catch from the connection closure as you will mask the original cause of the error. This semantic gets even better if you need to propagate the core SQL exception up to a common handler as it then looks even tidier:

Connection conn = ds.getConnection();
try
{
    //do some work with the connection.
    ...
}
finally
{
    try
    {
        conn.close();
    }
    catch(SQLException sqle)
    {
        LOG.error(sqle);
    }
}
//SQLException gets propagated out to another block of code handling it.