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

[Martin]

On 07/07/2010 13:54, Martin wrote:
> On 07/07/2010 13:30, Andrew Brunner wrote:
>> 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
....
> 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
....
> 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
>

And I forgot to return to the initial point ....

While object.free can throw an exception, in most cases it is not 
expected to do so. That means with most objects (at least those, that I 
use, or write), if an exception occurs during destruction, then that 
clearly is an exception of the 2nd kind. Therefore an exception that 
occurs in free/destroy (in my apps) indicates a none recoverable 
situation => and hence no more worries about leaks => only worries about 
saving as much userdata as possible.

so here is the code again
   obj1 := nil;
   obj2 := nil;
   try
     obj1 := tobj1.create;
     obj2 := obj1.createObj;
   //...
   finally
     obj1.free;
     obj2.free;
   end;


if " obj1.free; " crashes, then yes obj2 is not going to be released. 
But as explained in this and my last mail: It should not be attempted to 
be released.

if " obj1.free; " crashed, then the state of the app is unknown, 
anything that the app does from now on could cause more havoc. trying to 
free obj2 could destroy value-able user-data that otherwhise may still 
have been saved to a file.

I have an object, of  which I know that it can throw a recoverable 
exception within it's destructor, then I need nested try blocks. 
Otherwise (which in my case is the rule) I do not need nested try.

Martin

Disclaimer:
Having said that most objects are not excected to raise an exception in 
destruction => there are valid exception, and one has to know them, and 
act on them.