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

[Martin]

On 07/07/2010 13:30, Andrew Brunner wrote:
> 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.
>    
The initial exception does not have to be in Free or Destroy at all. If 
somewhere in the code a statement as follows is executed, then all bets 
are off

UninitializedPointerToRandomAddress := SomeValue;

You may have changed any other structure to anything. There is no waty 
to predict if the app can even continue to run, it can cause any amount 
of subsequent crashes.
It could have destroyed the memory-managers structures  of which memory 
is allocated. It could have modified other pointers, that now point to 
random addresses, it could have hit the stack and modified the return 
address, ....

With an exception like this, the rule is: Do as little as you can. 
Everything you do can make it worse. Call a function that relies on as 
little data as possible, and tries to simple save all user-data to an 
emergency file. Then exit


> Meaning, if you catch your exceptions FATAL errors will not even occur
> and there will be NO NEED to worry about restarting an application.
>    
Fatal errors don't alwasy need an exception in order to occur. They can 
occur even if all exceptions are caught.

They occur because with growing complexity of a software, the chances 
grow that the developper will introduce an error in the code.
If you argue that is not going to happen to you, then my 
congratulations. You must get a rather huge salary (million?), because 
if you look at the list of exploits in professional software, you will 
see that it happens to every other professional developper.

> 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.
>    
No of course an exception doe snot mean, that all is gone.

But you always have to know what the code that threw the exception was 
supposed to do.
If I write my own code then some methods I wrote are not expected to 
raise an exception (including they do not call any code that could ). 
Then there is no need for try blocks around this code, because if it 
does throw an exception, then it is an exception that can not be recovered.

As I said in my initial mail:
- There are exceptions that are intentionally risen. They can and should 
be handled correctly.
- There are exception that stem from errors in the implementation, they 
are not excpeted, and there is no way to assert how much dameage they 
have done

This mail was only about the 2nd kind of exception

Martin