Destructor semantics

[Don]

Steven Schveighoffer wrote:
> On Thu, 12 Aug 2010 13:05:53 -0400, Joe Greer <jgreer at doubletake.com> 
> wrote:
> 
>> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in
>> news:op.vhbtwjhoeav7ka at localhost.localdomain:
>>
>>>> Logically speaking if an object isn't destructed, then it lives
>>>> forever and if it continues to hold it's resource, then we have a
>>>> programming error.  The GC is for reclaiming memory, not files.  It
>>>> can take a long time for a GC to reclaim an object and you surely
>>>> don't want a file locked for that long anymore than you want it held
>>>> open forever.  My point is, that it is a programming error to expect
>>>> the GC be involved in reclaiming anything but memory.  IMO, the best
>>>> use of a finalizer is to error out if an object holding a resource
>>>> hasn't been destructed, because there is obviously a programming
>>>> error here and something has leaked. GCs aren't there to support
>>>> sloppy programming.  They are there to make your life easier and
>>>> safer.
>>>
>>> An open file maybe, but why should the compiler decide the severity of
>>> not  closing the resource?  What if the resource is just some
>>> C-malloc'd memory?

That's the only example of an nearly unlimited resource which I've heard 
thus far, but that raises the question, why the hell would you be using 
malloc if you're not going to free it, when you have a language with a 
gc? Effectively, the gc is freeing your malloced memory.

I can think of a couple of reasons for using malloc, but finalisers 
aren't a good solution to any of them.

> That's a possible solution.  I just don't like the blanket assumptions 
> being made.

Actually it's the absence of a use case.

Hypothesis: if a finalizer is run, where it actually DOES something (as 
opposed to, for example, running a pile of asserts), there's always a bug.

It's an extreme hypothesis, so it should be really easy to disprove.
Can you come up with a counterexample?