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

[Marcos Douglas]

On Wed, Jul 7, 2010 at 10:05 AM, Martin <fpc at mfriebe.de> wrote:
> 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.

Just one word, BRAVO!


MD.