Destructor semantics

[Joe Greer]

"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? 
> 
> Note, you are free to write your finalizer to do exactly what you want
>  (print some error if it's called and the file's still open).  I just
> don't  think the compiler should be involved in the decision, because
> it's too  ill-equipped to make one.
> 
> -Steve

I think you misunderstand what I was saying.  The compiler doesn't decide 
any of that.  The programmer conserned with correctness has the option of 
making his finalizer complain about unfreed resources.  I language 
shouldn't be your nanny, but it should encourage and enable you to do the 
right thing.  There is just no substitute for knowing how to program.

joe