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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
