CODEWITHSUNDEEP
delphiexceptiondelphi-5
Stuart Golodetz
Stuart Golodetz

Reputation: 20616

In Delphi 5, can Free ever raise an exception?

In Delphi 5, I've currently written code that calls Free on multiple variables in a finally block, e.g.

...
finally
    a.Free;
    b.Free;
    c.Free;
end;

This code assumes that Free can never raise, since if, for example, a.Free raised, the memory for b and c would be leaked. Is this assumption justified?

Upvotes: 7

Views: 1060

Answers (5)

Vahid Nasehi
Vahid Nasehi

Reputation: 463

There could be 2 things that can cause SomeObj.Free to raise an exception:

  1. Unhandled exception in destructor of the SomeObj instance of class or on of its ancestors.
  2. Invalid class reference due to uninitialized variable SomeObj.

In your case if a.Free raises an exception for any of the above reasons, there would be a memory leak for object b and c and maybe some leak inside object a because of unhandled exception in destructor.

Upvotes: 2

David Heffernan
David Heffernan

Reputation: 612794

The Free method itself does not explicitly raise an exception, but it calls the virtual destructor Destroy which certainly could raise an exception.

So if you want to be sure that all your objects are destroyed, even if one of the destructors raises an exception you end up with code like this:

a := TMyObject.Create;
try
  b := TMyObject.Create;
  try
    ...
  finally
    b.Free;
  end;
finally
  a.Free;
end;

Having said that, it should be a design principle that you do not raise exceptions in a destructor. So, in my view it's perfectly reasonable to take the viewpoint that if an exception is raised in destructor, then your program is pretty much hosed. Leaking objects at that point is not something to worry about. If your destructor has raised an exception then you are probably already leaking because that destructor did not run to completion.

So in my view it can be perfectly reasonable to group together some calls to Free and of course you avoid deeply nested try/finally which is something worth striving for.

If you want just one try/finally then remember to write the code like this:

a := nil;
b := nil;
try
  a := TMyObject.Create;
  b := TMyObject.Create;
  ...
finally
  b.Free;
  a.Free;
end;

In my own code base I have some helper methods that make this cleaner. Then the code can look like this:

InitialiseNil(a, b);
try
  a := TMyObject.Create;
  b := TMyObject.Create;
  ...
finally
  FreeAndNil(b, a);
end;

I have given my FreeAndNil the same name as the function in SysUtils which on first glance may seem odd, but it is safe and benign to do so. Naturally these helpers come into their own when you have even more than two objects.

Upvotes: 11

RBA
RBA

Reputation: 12584

if your a.free raise an exception, a(depending on how much the destructor has freed up from the the a's object fields), b and c objects will be leaks because the execution will be interrupted. Anyway, something is wrong in your destructor, if it raises an error. so, you should protect the code with try..finally blocks, but IMHO you should verify that destructors don't give you in any circumstance errors.

Upvotes: 1

Paul Foster
Paul Foster

Reputation: 75

Of course FREE can emit exceptions - so yes, you will leak memory in your code if A.FREE emits an exception, B.FREE and C.FREE will not be called.

The question is, do you want to handle the exceptions or let them happen? Its going to depend on what your code is going to be for, are other devs going to be using it (for example). To prevent any memory leakage you should nest the try..finally sections;

a:=tobject.create;
try
  b:=tobject.create;
  try
    c:=tobject.create;

    ...

  finally
    c.free;
  end;
finally
  b.free;
end;
a.free;

Sort of thing. Its a question of what your code is actually doing as to if you should also wrap the A.FREE in a try..finally section too, although I'm guessing you probably should.

Upvotes: 0

Ondrej Kelle
Ondrej Kelle

Reputation: 37211

Depends on what's happening in the destructor.

Upvotes: 3

Related Questions