[fpc-pascal] methods of an object to create others objects

Andrew Brunner andrew.t.brunner at gmail.com
Wed Jul 7 05:25:42 CEST 2010


On Tue, Jul 6, 2010 at 8:14 PM, Marcos Douglas <md at delfire.net> wrote:
> On Tue, Jul 6, 2010 at 7:14 PM, Andrew Brunner
> <andrew.t.brunner at gmail.com> wrote:
>> On Tue, Jul 6, 2010 at 5:09 PM, Graeme Geldenhuys
>> <graemeg.lists at gmail.com> wrote:
>>> Even with a try..except, if you call MyObj.Free and it causes an
>>> exception, you are screwed either way and it will always cause a
>>> memory leak. Best is no notify the user some how, or crash out of the
>>> program, or fire the programmer for not writing enough unit tests. :)

The caveat is that exceptions in the Destroy does not necessarily mean
a memory leak.  The exception object will be taken care of.  So just
make sure the Destroy methods free what they are supposed to free.

>> No, if the nesting is done properly you could guarantee that Obj2.Free
>> would be called even if Obj1.Free failed with some exception.  And
>> further, nested exception handling offers safeguarding against such
>> memory leaks during destruction if done properly.  To me this is the
>> difference between good software and great software... How well it
>> handles exceptions.
>
> Okay, you're right. Nesting exception handling is the only way to
> avoid memory from leaking, in these cases.


> And now? Your program failed (e.g.) using Free method... you assured
> there is no memory leaking (using nesting exceptions), but this is a
> totally _unexpected_ exception!
> IMHO the program should be aborted, the user is notified, log this
> error... start again.

I must admit I am not a subscriber of any practice that allocates with
out strategizing where the memory will be reclaimed.  Everything I do
is accounted for.  So I just don't see any of these issues with
memory.  But because the power is in the developer... this issue is
paramount to developing stable code.

> If the program is a web app, you can't abort immediately (no?)... but
> you'll do it sometime  ;-)

Yes.  My experience is predominately based on a Social Computer Server
engine where it is just not advisable to leak memory.  I can move it,
allocate, deallocate but I just don't have any instances of where I
see memory leaking.  And if there are leaks rebooting the device or
server software is just not an option.

> I'm more concerned with programming errors that can not see
> immediately, such as forgetting to free some object. For me, an
> Exception is an exception! I did not expect and I need do something
> (if the program does not have its own treatment for what occurred).

>From the FPC development team prospective you would be correct.  From
other developers using FPC prospective - if they find themselves
having memory issues a Managed development platform with garbage
collection would be advisable.



More information about the fpc-pascal mailing list