On Wed, Jul 7, 2010 at 8:05 AM, Martin <f...@mfriebe.de> wrote:
>
> 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.
>
Martin, I can't disagree more. I find it completely ludicrous that if
obj1.free raises an exception you should just trow the baby out with
the bath water. If Obj1.Free raised an exception because a disk drive
was unmounted... Inspect the log... Handle the exception... And fix
the problem. Future instances will be handled and all is good. It is
my belief that the notion of skipping exception handling and
restarting an application is very bad practice.
> 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.
LOL. If something inside Obj1.free HAD EXCEPTION handling you would
catch the error and understand what caused it.
procedure TObj1.Free;
begin
Disk1.Unmount; <<< The disk object is missing now b/c a network failure;
Inherited Destroy;
end;
procedure TObj1.Free;
begin
Try
Disk1.Unmount;
Except
On E:Exception do begin
// Some case stuff here
end;
end;
Inherited Destroy;
end;
In my example... Your code would blow out an application. With my
exception handling the app would continue on as normal with no
problems.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
