On 07/07/2010 13:30, Andrew Brunner wrote:
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.
The initial exception does not have to be in Free or Destroy at all. If
somewhere in the code a statement as follows is executed, then all bets
are off
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 of which memory
is allocated. It could have modified other pointers, that now point to
random addresses, it could have hit the stack and modified the return
address, ....
With an exception like this, the rule is: Do as little as you can.
Everything you do can make it worse. Call a function that relies on as
little data as possible, and tries to simple save all user-data to an
emergency file. Then exit
Meaning, if you catch your exceptions FATAL errors will not even occur
and there will be NO NEED to worry about restarting an application.
Fatal errors don't alwasy need an exception in order to occur. They can
occur even if all exceptions are caught.
They occur because with growing complexity of a software, the chances
grow that the developper will introduce an error in the code.
If you argue that is not going to happen to you, then my
congratulations. You must get a rather huge salary (million?), because
if you look at the list of exploits in professional software, you will
see that it happens to every other professional developper.
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.
No of course an exception doe snot mean, that all is gone.
But you always have to know what the code that threw the exception was
supposed to do.
If I write my own code then some methods I wrote are not expected to
raise an exception (including they do not call any code that could ).
Then there is no need for try blocks around this code, because if it
does throw an exception, then it is an exception that can not be recovered.
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
Martin
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
