Board index » delphi » Problem with destructor

Problem with destructor

Hi there

I've got a problem with destructor.
I thought after a call to the destroy
method of an objet, the reference of
this object would be nil, but after
calling the destroy method of my object,
the reference is not nil, and the object
inspector, by debugging, seems to show that
there the object is not empty.
But, if I try to acces to a method of this
object after calling the destructor, I've
got an exception.

So my question is :
Is the object totally freed, and that's just
the reference which is not set to nil, or is
the object incompletedly desallocated ?

Eddy

 

Re:Problem with destructor


"bloublou" <capp...@yahoo.com> skrev i melding
news:9faee48e.0107110751.61318120@posting.google.com...

Quote
> Hi there

> I've got a problem with destructor.
> I thought after a call to the destroy
> method of an objet, the reference of
> this object would be nil, but after
> calling the destroy method of my object,
> the reference is not nil, and the object
> inspector, by debugging, seems to show that
> there the object is not empty.
> But, if I try to acces to a method of this
> object after calling the destructor, I've
> got an exception.

> So my question is :
> Is the object totally freed, and that's just
> the reference which is not set to nil, or is
> the object incompletedly desallocated ?

Yes, the object is freed, but your reference is now invalid. It points to the
very same address, no longer contains any object instance. The memory isn't
cleared, though, so you may accidentially mistake the reference for a valid
one.
Be careful about memory references, if you{*word*222}up here, you may have a
really hard time finding your bug. There are two major ways to avoid invalid
references: 1) By careful programming, allways 100% in control of all
possible flow directions, and 2) Allways clear an object reference once it's
freed. These strategies have been thoroughly discussed in this NG recently,
but there are general guidelines to follow:
1) Whenever you write a Create(), write the corresponding Free; call.
2) Be careful about program flow in case of exceptions, breaking out of a
program block because of an exception should not instantly create an
EAccessViolation. Example:

bad:
-------

var
  SL1: TStringList;
  SL2: TStringList;
begin
  SL1:=TStringList.Create;
  try
    SL1.LoadFromFile('c:\autoexc.bat'); // <- Exception here
    SL2:=TStringList.Create;
    SL2.LoadFromFile('c:\config.sys');
    // Do stuff with string lists here...
  finally
    SL1.Free;
    SL2.Free; // ... Leads to EAccessViolation here
  end;
end;

good:
--------
var
  SL1: TStringList;
  SL2: TStringList;
begin
  SL1:=TStringList.Create;
  try
    SL1.LoadFromFile('c:\autoexc.bat'); // <- Exception here....
    SL2:=TStringList.Create; // ...or here (resulting in an invalid object
ref.)...
    try
      SL2.LoadFromFile('c:\confg.sys'); {SL2 should be freed if you reach
here}
    // Do stuff with string lists here...
    finally
      SL2.Free;
    end;
  finally
    SL1.Free;// ... moves you here...SL2 is not freed !
  end;
end;

...or simpler, by adding this line in the first example:

->  SL2:=nil; // SL2 may now be freed even if not created
  SL1:=TStringList.Cre....etc..

One could argue that "an exception occurs, so what the heck..", but
AccessViolations is an enemy as they obscure what's really going on. Very few
of exceptions from object references are caused by invalid references in the
beginning, merely as a result of incomplete handling of the occurred
situation. The above example results in an EAccessViolation when the problem
was, in fact, a misspelled filename leading to an EFOpenError exception. The
first exception will never reach any exception handlers, as it is "replaced"
in the finally...end block (AMOF is, I just exactly now realized the impact
of this as I tested the code above...).

Test the above examples, the latter one also with a correct filename for SL1.
Stepping illustrates it...!

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorgeremovet...@itte.no (remove the obvious)

Other Threads