[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