4

I am getting a compiler warning I don't understand:

procedure Test; var Var1: Integer; begin while True do begin try if System.Random > 0.5 then begin ShowMessage('Skipping'); continue; // If I remove this line, the warning goes away end; Var1:=6; except on E:Exception do begin ShowMessage('Error'); raise; end; end; ShowMessage(IntToStr(Var1)); // Compiler warning on this line end; end;

When I compile this in Delphi 2010 I get:

[DCC Warning] OnlineClaimManagerMainU.pas(554): W1036 Variable 'Var1' might not have been initialized

If I remove the call to 'continue', the warning goes away.

Also, if I remove the try/except clause (and leave the continue), the warning goes away.

How will execution get to the line in question without Var1 being initialised?

Improve this question
5
  • 1
    The compiler's analysis is not as deep as yours. It can't be sure that Var1 has been initialised. You know that Var1 is always initialised but the compiler does not have your analytic talents. Commented Jul 19, 2012 at 6:12
  • So... why does removing the continue fix it? The same problem would apply. Or is it just the sheer complexity of the combination of both that blows the compilers mind? Commented Jul 19, 2012 at 6:21
  • Add Var1:=0; before while to make the compiler happy. Commented Jul 19, 2012 at 6:21
  • I guess the presence of the continue means the compiler's analysis is harder. Interestingly I once had some code that I knew was fine but that the compiler warned about, in x86 but not x64. I made the obvious change and then x86 compiler was quiet, but x64 complier whined!! Very odd. Commented Jul 19, 2012 at 6:25
  • @cesar that's missing the point. The question is about why the compiler warns about something that can never happen. Commented Jul 19, 2012 at 6:29

3 Answers 3

Reset to default
4

Var1 will always be initialised before it is used. The compiler gets confused by try-except handling: your code is too complex for the compiler to be able to actually determine that Var1 is always initialised. It sees there may be a handled exception before Var1:=6;, which would leave Var1 uninitialised, but it doesn't see that that exception will always be re-raised.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

It will not, local not managed variables is not auto initialized.
@Cesar hvd means always initialised before use
0

You should but the ShowMessage(IntToStr(Var1)); into the try except block. Then it should be clear to the compiler, that Var1 is intialized and looks more as clean code.

Improve this answer

1 Comment

Doing that means that if ShowMessage causes an exception (yes, it can do that, and besides, I'm assuming it's simplified from code that does more than just call ShowMessage), the exception handler will run, while it won't in the code in the question.
0

It is a farily good warning. What it tells that you do not assign any value to the variable which may be used somewhere else in your code. Warning also tells that if it's used then the value assigned to it may be not what you expect.

Improve this answer

4 Comments

I think you haven't understood the question.
@Rob Kennedy I think you misunderstood my answer. Value to Var1 is not being assigned in paths. Hence the warning. If you disagree please add some value to your comment.
Very well. The question didn't ask what the warning means. It asked why the warning was given in this context, especially since seemingly unrelated changes affect the warning's appearance. It's clear to humans that Var1 is assigned at the point the warning indicates, but the compiler doesn't see that. Your answer suggests you think the warning is right; please show how.
I see it now, call to ShowMessage(IntToStr(Var1)) is only executed when Var1 value is assigned. So the warning doesn’t actually makes sense. Thanks Rob K. for kindly letting me it to figure out.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.