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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
