Proposal: Automatic Resource Management
jjb at google.com
Tue Mar 3 19:41:18 PST 2009
I think you may be missing the point here. The only use of this interface
would be to make a type eligible for automatic resource management. It
would never be used as a parameter type. There'd be no pain at all
associated with it.
On Tue, Mar 3, 2009 at 6:47 PM, Neal Gafter <neal at gafter.com> wrote:
> I guess I assumed you were aware why people complain about
> Closeable.close() throwing IOException. Josh alluded to this when he
> said that Disposable won't be terribly useful as a parameter type.
> When you pass it somewhere, the receiver must assume that the close()
> method throws any Exception, and that forces the receiver to write
> code to handle the whole Exception hierarchy. I think it's likely
> that programmers would want to pass a Disposable around so that the
> receiver can put a region of code under control of the resource (i.e.
> dispose it when the receiver arrives at some particular point of
> completion). I'm afraid this would just be trading one set of pain
> points for another.
> On Tue, Mar 3, 2009 at 6:26 PM, Reinier Zwitserloot
> <reinier at zwitserloot.com> wrote:
> - Show quoted text -
> > The new Disposable idea makes this proposal much cleaner, Josh. I like
> > it.
> > Neal, could you perhaps elaborate on the pain that Disposable is going
> > to cause? Insinuating that proposals are Bad Ideas without any
> > specifics whatsoever seems better suited to some sort of voting cycle.
> > On this mailing list it seems counter-productive to say the least.
> > --Reinier Zwitserloot
> > On Mar 4, 2009, at 03:08, Neal Gafter wrote:
> >> Given all the gnashing of teeth over the fact that Closeable's close
> >> method throws IOException, I can only imagine the pain that
> >> Disposable.close() throwing Exception will cause.
> >> On Tue, Mar 3, 2009 at 5:47 PM, Joshua Bloch <jjb at google.com> wrote:
> >>> I have modified the proposal in light of Mark's example. The only
> >>> change is
> >>> that the Disposable interface is no longer parameterized. This
> >>> eliminates
> >>> the incompatibility noted by Neal; so far as I know, the revised
> >>> proposal
> >>> introduces no incompatibilities. It can be found here:
> >>> http://docs.google.com/Doc?id=ddv8ts74_0vnstdfdh .
> >>> Happy reading,
> >>> Josh
More information about the coin-dev