On Wed, Jul 7, 2010 at 2:09 AM, Graeme Geldenhuys <graemeg.li...@gmail.com> wrote: > Op 2010-07-07 03:32, Martin het geskryf: >> >> And in the 2nd case, mem leaks are no worry => the app is going to be >> closed, mem will be freed by the OS. >>[...snip...] >> >> The whole memory management could be corrupted. Trying to free >> memory could just cause more and more exceptions. > > > That is exactly what I was trying to explain to Andrew. If freeing an > instance is what caused the exception, no amount of try..except or > try..finally blocks will help you - you still can't free the instance, so > better notify the user to try and save, then quit the app and start again. > 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 if you would assume that all exceptions raised in Obj.Free were handled - since my assertion is all developers using a non-managed platform like FPC. I'm saying that because if memory is allocated, and deallocated you will not blow-out the memory manager in FPC. Meaning, if you catch your exceptions FATAL errors will not even occur and there will be NO NEED to worry about restarting an application. Its a clean way of thinking. I have no worries. When I call Obj.Free it can raise exceptions, and still recover to the calling methods - whether we are talking about ObjX.free or ObjX.DoSomething.
My basic point is that just because an exception is raised does not mean the method will blow-out. It will be handled. LOL... With exception handling (often nested) where required. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
