2

I have this example method below

procedure ReadData(var data:TDataSet)
begin
   if Assigned(data) then
      data.Free;
   data:=TDataSet.Create(nil);
   ....
end;

.....
procedure SomethingProcedure()
var
   dataSet:TDataset;
begin
   ReadData(dataSet);
end;

if I debugged and I place breakpoint on Assigned checking, data.Free always executed, and I saw on watch list, data always inaccessible value

My point is SomethingProcedure is access for many other procedure, and I want data parameter if it assigned (already created TDataset object), free it first, but if not assigned (not created object), free command doesn't execute, but free statement always executed, either "data" object created or not

How I can check my object already created or not

navirius
  • 209
  • 1
  • 7
  • 14

2 Answers2

4

You have some issues with your code example

  • You declare dataset but pass data in your Init procedure
  • The if statement doesn't have a then in your ReadData procedure

All in all, you can not have been debugging the example you've given so I'm going to make some assumptions here.


I believe your actual problem is coming from the fact that local, not finalized variables do not get initialized to zero/nil. The dataset variable in your Init procedure contains whatever garbage happens to be at the location the variable points to.

Which variables are initialized when in Delphi?

As you don't initialize the local variable dataset (something you should always do with local variables), Assigned will return true (all it does is check for nil) and free will get called.

Most of the time and if you are lucky, the call to free will throw an AV. Worst case, it will succeed and you will have a really hard time figuring out why something is going wrong.


Edit

I assume by your edit that you mean that ReadData is called in many other procedures?

If that's the case, there really is not a lot you can (or for that matter should) do to protect you from callers passing in garbage. What you should do is fix the callers.

Fix the root cause, not the symptoms

Community
  • 1
  • 1
Lieven Keersmaekers
  • 57,207
  • 13
  • 112
  • 146
  • @navirius - Your edit doesn't alter anything about what I and Wodzu already told you. FTR - The `SomethingProcedure` still doesn't compile. Your local variable name doesn't match with what you pass to `ReadData`. – Lieven Keersmaekers May 02 '13 at 06:15
  • as a sidenote even if the calls are fixed, data.Free will leave a invalid variable data, which has to be set to nil. – bummi May 02 '13 at 06:40
  • @bummi - Good point. I do assume the variable will get assigned a new value later in the procedure. – Lieven Keersmaekers May 02 '13 at 07:40
  • yeah, you right, after free, I assign TDataset.Create(nil), what I mean is, if it already created object, free it first, then I create, but the fact is, created or not created the "data" object, data.free still executed... – navirius May 02 '13 at 07:43
  • @bummi I think I got your point, I suddenly had enlightment with nil assignment to object, thanks to you, it work now, I suppose not to believe to delphi about initial value of variable :( – navirius May 02 '13 at 07:49
3

First of all, you do not have to check your data object for assignment. It is perfectly safe to call Free method when data is pointing to nil.

As for the reason why you can not see on what the data is pointing to: you probably need to turn off the optimization for your project. To do this go to: Project > Options > Delphi Compiler > Compiling (this may vary depending on your Delphi version) and switch Optimization to False.

Wodzu
  • 6,932
  • 10
  • 65
  • 105
  • In fact the first point is the whole point of `Free` as opposed to `Destroy`! – Gerry Coll May 02 '13 at 06:00
  • You are right, you can call free if data is pointing to nil. But this is not the point in this question, even set optimization to false won't initialize local variables. – bummi May 02 '13 at 06:35
  • @bummi My first paragraph was just a sidenote. The thing is that the question has been changed by navirius after my answer. In the first instance of his question he was asking for **something different**. Unfortunately, now my answer looks offtopic:) – Wodzu May 02 '13 at 08:52