On Tue, Jul 6, 2010 at 8:14 PM, Marcos Douglas <m...@delfire.net> wrote: > On Tue, Jul 6, 2010 at 7:14 PM, Andrew Brunner > <andrew.t.brun...@gmail.com> wrote: >> On Tue, Jul 6, 2010 at 5:09 PM, Graeme Geldenhuys >> <graemeg.li...@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. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
