The Real Questions.

I've been watching the various manoeuverings going on in parliament to change various aspects of the balance between the legal system and the political system in this country.

When misgivings are raised, the politicians always seem to justify their actions on two bases:

• It is necessary because the current system is unwieldy/expensive.
• Don't you trust us/me?

The real questions that should be asked of the politicians are:

• Whether I trust you or not is irrelevant. Can I trust your successors? Can you guarantee that the 2nd, 3rd or 4th set of politicians to be voted in won't abuse the powers that you are giving them?
• Don't you think it is worth the inconvenience/expense in order to guarantee a reasonable level of freedom from oppression?

I wonder whether we will ever see these questions posed clearly, well and in a situation where the politician is forced to answer.

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.

A Connection Pool That Satisfies a Previous Rant

A little while ago I was talking about how many connection pools do not properly satisfy the JDBC specifications (Here.). Many home rolled connection pools do not close the resources associated with a connection before returning it to the pool.

I finally pulled my finger out and decided to have a look for a connection pool that behaved properly. Having pulled the source code for a number of connection pools (and shuddered once or twice when reading), I found a connection pool that actually works properly: Apache Commons-DBCP. The connection pool keeps track of all Statements that are created and closes them and their associated resources when the connection is returned to the pool.

As long as this pool is used, we can avoid all the JDBC clutter in our finally blocks and just close the connection when we're done.