Automatic Resource Management

[Peter Levart]

On Tue, Apr 14, 2009 at 1:54 AM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> Having said that, there might be a way out of this, by integrating both
> proposals.
>
> 1. Remove the ability to put multiple resources in one statement; what's
> the problem with nesting trywith blocks again?
>
> 2. Use the ; to switch to the alternate form of resource management: try (
> a ; b ) {} no longer requires that is an expression of type 'Disposable' (or
> a variable declaration of a Disposable), and instead, b is run at the end
> analogous to your proposal.
>
> Then, for all objects that know how to dispose of themselves, you just go
> try ( object ) { stuff }, but when they don't, you can work around it with
> try ( object ; closeIt ) { stuff }.


That's a great idea. It would encourage people to build APIs around a common
interface but still allow using a different style of programming or enable
proper resource cleanup even in situations where the shear reference to the
resource is not enough to dispose it. What am I talking about?


> NOTE: I'm not actually in favour of this, because, at the risk of taking a
> contentious position, I don't rate the libraries that can't deal with
> Disposable very highly. SWT was absolutely excellent when it was released,
> and the java community owes it a great thank you for lighting the fire of
> competition under awt/swing's behind, but between new swing versions and
> javaFX, SWT's time has gone, eclipse needs to migrate over, and SWT needs to
> slowly but surely go away now. Locks are handled just as well, IMO, with the
> existing try/finally structure, primarily because lock.unlock() generally
> doesn't throw exceptions, which is a big reason for using ARM in the first
> place.
>
>  --Reinier Zwitserloot


... I'm thinking of numerous situations where propper clean-up is the
responsibility of third party code, not the resource itself. This is usually
the case of libraries that are build as a wrapper arround some other
lower-level API and expose references to lower-level resources. Take for
example Hibernate. There's a snippet of code from an "identity generator"
(the resources are not closed optimally here since exceptions thrown in
resource cleanup override main exceptions. The reason? Probably laziness):

        try
        {
            PreparedStatement st =
session.getBatcher().prepareSelectStatement(sql);
            try
            {
                ResultSet rs = st.executeQuery();
                try
                {
                    rs.next();
                    return rs.getLong(1);
                }
                finally
                {
                    rs.close();
                }
            }
            finally
            {
                session.getBatcher().closeStatement(st);
            }
        }
        catch (SQLException sqle)
        {
            throw JDBCExceptionHelper.convert(
                session.getFactory().getSQLExceptionConverter(),
                sqle,
                "could not execute select statement",
                sql
            );
        }

... here a special class called Batcher is the manager of the JDBC resource
called PreparedStatement. Proper initialization and cleanup is it's
responsibillity. You may argue that Hibernate should not "leak" lower-level
API through it's own API and should wrap PreparedStatement in it's own
class. That is the ideal world. In reality this is often practiced to make
code more "economic".


Regards, Peter