Proposal: Automatic Resource Management
jjb at google.com
Tue Mar 3 17:22:12 PST 2009
Sorry for the delay, and thanks so much for the report! This is an
interesting case. It seems unfortunate that DataCacheManagerImpl extends
Closeable, given that its close method doesn't throw any checked exceptions.
But it got me thinking, and I came to the conclusion that there's no reason
for the Disposable interface to be parameterized! Its close method should
just throw Exception. Then Closeable and DataCacheManager can both extend
Disposable. The Disposable interface won't be terribly useful as a parameter
type, but who cares? Its raison d'etre is the automatic resource management
statement. In this context, the close method is invoked on a resource using
its declared type. That means that it throws whatever exceptions it's
declared to throw (as per the desugaring in my proposal). I will modify the
proposal accordingly and repost it. I think this is a real improvement!
It's both simpler and more broadly applicable.
Thanks so much,
On Sun, Mar 1, 2009 at 1:54 AM, Mark Mahieu
<mark at twistedbanana.demon.co.uk>wrote:
> On 28 Feb 2009, at 19:08, Joshua Bloch wrote:
>> On Sat, Feb 28, 2009 at 7:41 AM, Neal Gafter <neal at gafter.com> wrote:
>>> The compatibility section must document incompatibilities, whether or
>>> not you judge them likely to cause problems in practice.
>> Good point. I will add this one. And I am still interested in whether
>> anyone can find some code in an existing codebase that tickles this.
> The worst case I've turned up so far is the following, which would not be
> broken by your proposal, but I think it would be restricted in its ability
> to take advantage of it without further changes downstream:
> Here, the class DataCacheManagerImpl implements two interfaces, both of
> which could logically be retrofitted with Disposable<X>, but doing so would
> then break DataCacheManagerImpl since different type arguments would be
> needed (Exception and RuntimeException).
> (I think the idea is that an alternative implementation of DataCacheManager
> can be specified by the user of this library; it seems quite likely that
> these would extend the default DataCacheManagerImpl implementation.)
> Depends on how ticklish you are I guess. For me it's a hint that an
> interface may not be the best mechanism.
More information about the coin-dev