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

[Andrew Brunner]

On Wed, Jul 7, 2010 at 2:09 AM, Graeme Geldenhuys
<graemeg.lists at gmail.com> wrote:
> Op 2010-07-07 03:32, Martin het geskryf:
>>
>> And in the 2nd case, mem leaks are no worry => the app is going to be
>> closed, mem will be freed by the OS.
>>[...snip...]
>>
>> The whole memory management could be corrupted. Trying to free
>> memory could just cause more and more exceptions.
>
>
> That is exactly what I was trying to explain to Andrew. If freeing an
> instance is what caused the exception, no amount of try..except or
> try..finally blocks will help you - you still can't free the instance, so
> better notify the user to try and save, then quit the app and start again.
>
Ok.  I think I understand the discrepancy in our reasoning.  The issue
is when exceptions are raised during Obj.Free.  I think it would help
if you would assume that all exceptions raised in Obj.Free were
handled - since my assertion is all developers using a non-managed
platform like FPC.  I'm saying that because if memory is allocated,
and deallocated you will not blow-out the memory manager in FPC.
Meaning, if you catch your exceptions FATAL errors will not even occur
and there will be NO NEED to worry about restarting an application.
Its a clean way of thinking.  I have no worries.  When I call Obj.Free
it can raise exceptions, and still recover to the calling methods -
whether we are talking about ObjX.free or ObjX.DoSomething.

My basic point is that just because an exception is raised does not
mean the method will blow-out.  It will be handled.  LOL... With
exception handling (often nested) where required.