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

Martin fpc at mfriebe.de
Wed Jul 7 03:32:21 CEST 2010


On 07/07/2010 02:14, Marcos Douglas wrote:
>
>> 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.
>    

+1

In fact trying to handle exceptions, that aren't supposed *can* even 
make it worse.

There are 2 ways an exception can happen.

1) intended use to indicate some error => the programmer knows and can 
set "try" blocks exactly where needed.

2) exceptions that are unexpected. A malfunction in the program. => tell 
the user to save the data, if possible, and exit the app asap.

And in the 2nd case, mem leaks are no worry => the app is going to be 
closed, mem will be freed by the OS.
But trying to free mem, could just create even more havoc. Imagine the 
exception was because of some random memory access (some uninitialized 
pointer). The whole memory management could be corrupted. Trying to free 
memory could just cause more and more exceptions.

Martin



More information about the fpc-pascal mailing list