"Steven Schveighoffer" <[email protected]> wrote in news:[email protected]:
>> 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
