On Wed, Jul 7, 2010 at 10:05 AM, Martin <f...@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. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
