[fpc-pascal] methods of an object to create others objects
fpc at mfriebe.de
Wed Jul 7 15:05:56 CEST 2010
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;
obj1 := tobj1.create;
obj2 := obj1.createObj;
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
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.
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.
More information about the fpc-pascal