Proposal: Automatic Resource Management

[Sean R. Drucker]

My suggestion was assuming an implementation like (2).  Here is a use case:

interface SQLIterator<E> extends Iterator<E>, Disposable<SQLException> {
}

interface SQLTable extends Iterable<Row> {
     SQLIterator<Row> iterator();
}

Current usage pattern:

public static void current(SQLTable table) throws SQLException {
     final SQLIterator<Row> itr = table.iterator();
     try {
         while (itr.hasNext()) {
             final Row row = itr.next();
             ...
         }
     } finally {
         itr.close();
     }
}

Equivalent using Automatic Resource Management:

public static void arm(SQLTable table) throws SQLException {
     for (final Row row: table) {
        ...
     }
}

The specification added to Disposable would be something like:

If an implementation of Iterable<E>.iterator() returns a static type 
that extends both Iterator<E> and Disposable<X> (which is possible due 
to covariance), then when an instance of that Iterable is used in a 
for-each loop, the Iterable.iterator() will always have its 
Disposable.close() method called after iteration is complete or 
terminated (either an early return or an iteration exception).  Any 
checked exception X thrown from Disposable.close() will need to be 
caught or rethrown and will suppress any prior iteration exception.

Suppressing exceptions seems reasonable as that is what is done in the 
current usage pattern.  Also, as a practical matter, if a close() method 
was ever to throw an exception (which is highly rare), it would indicate 
a far greater problem (usually a lost resource connection) than any 
problem in the iteration.

Thanks... Sean

Neal Gafter wrote:
> On Tue, Sep 1, 2009 at 4:24 PM, Rémi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
> 
>     This will require to introduce a new interface IterableDisposable or
>     something like that to ease the use of such pattern.
> 
> 
> That's one way to do it.  Here are two others:
> 
>  1. Dynamically test the type of the iterator to see if it extends 
> Disposable.
> 
>  2. Statically test the static return type of 
> iterableExpression.iterator(), which due to covariance may be a type 
> that extends both Iterable<?> and Disposable.
> 
> I think (2) works best, so that the compiler can see the exceptions 
> statically thrown by iterableExpression.iterator().close() and the 
> programmer won't have to catch(Exception).
> 
> Cheers,
> Neal
>