(tye)Re: Weird Warning
by tye (Sage) on Jun 25, 2001 at 07:37 UTC
|
My first guess was that $key is undef. But I'll get back to that...
The respondant who said that either $SERVER{$key}{one} or $SERVER{$key}{two} is undef was wrong. The one who said that printing "0" instead of the empty string meant that neither of those is undef is correct.
But my first guess is also wrong because you didn't get the warning from the print statement. So my final guess is that one of the else or one of the elsifs associated with that if is really where the warning is coming from.
For some reason, Perl often (always?) reports errors in the else and elsifs as if they came from within the if. I used to think that this was due to an optimization trick but that trick was only done in Perl 4.
-
tye
(but my friends call me "Tye")
| [reply] [d/l] |
|
Doh! Forgot to login above. Should have noticed the lack of sig. The problem was really in the elsif below the if. You were right, tye. Thanks a lot! Now my program is running great with strict & -w with zero warnings.
-billyak
| [reply] [d/l] [select] |
Re: Weird Warning (boo)
by boo_radley (Parson) on Jun 25, 2001 at 02:00 UTC
|
it means that either
$SERVER{$key}{one} or $SERVER{$key}{two} is undef.
As for what the correct way to solve it is, that depends on the application itself. If it's critical that these variables do have some meaning, something like die "server key one not defined" unless defined ($SERVER{$key}{one}); will tell you when the first one's undefined. If it's ok, then there's a variety of things you can do, but you'll need to check for definedness in (I think) any case.
| [reply] [d/l] [select] |
Re: Weird Warning
by lemming (Priest) on Jun 25, 2001 at 07:05 UTC
|
Since you get zeros instead of blanks, you
don't have uninitialized values in the print. I suspect
a typo in the if statement.
mannequin approach: Call someone over to look at
the problem, but just as they get there look at the code
again. You'll probably spot the error.
| [reply] |
Re: Weird Warning
by Anonymous Monk on Jun 25, 2001 at 02:31 UTC
|
They ARE initialized! It even prints the error when the "test" line reads:
1 == 1 && 1 == 1
| [reply] [d/l] |
|
#!/usr/bin/perl
use strict;
use warnings;
use diagnostics;
my %SERVER;
my $key = 1;
$SERVER{$key}{one} = $SERVER{$key}{two} = 1;
print "$SERVER{$key}{one} == 1 && $SERVER{$key}{two} == 1\n";
if($SERVER{$key}{one} == 1 && $SERVER{$key}{two} == 1){
}
prints:1 == 1 && 1 == 1but no warning.
HTH,
Charles K. Clarkson
| [reply] [d/l] [select] |
Re: Weird Warning
by Aighearach (Initiate) on Jun 25, 2001 at 02:14 UTC
|
If you're using Perl 5.6.x you can remove -w and add use warnings instead. Then, you can do:
print "$SERVER{$key}{one} == 1 && $SERVER{$key}{two} == 1\n";
no warnings 'uninitialized';
if($SERVER{$key}{one} == 1 && $SERVER{$key}{two} == 1){
...
}
use warnings 'all'; # I think it's a nice warning, I never want it off
+ for very long... ymmv
-- Snazzy tagline here
| [reply] [d/l] |
|
I didn't want to use the weenie method and localize the warning variable to stop this warning; what is the correct way to fix this?
Mabey you aren't using a variable, but I think this isn't in the spirit of what the poster wants.
The 15 year old, freshman programmer,
Stephen Rawls
| [reply] |
|
Maybe it is, maybe it isn't, but it is the best way to do it. The only other things you can do are add lots of tests or turn off all warnings. Lots of tests can be clunky, and no warnings at all means you have to keep the code locked in the basement where nobody can see it. ;)
But, most of the complaints about the old way of turning off warnings aren't relevant to the new pragma. It _is_ bad to be messing with localized vars to control the compiler or interpreter. It got the job done, but I'm sure happy for the warnings pragma and filehandles as objects... it lets me throw local out of my box altogether.
-- Snazzy tagline here
| [reply] |
|
Please do not do this.... This is akin to turning up the radio so you don't hear the nasty sounds your engine is making. The warning is there because you are likely missing a condition that you did not think of, turning off warnings only removes the message not the problem it is warning you about.
| [reply] |
|
warnings are a good thing. I'd never just turn them off to begin with. But saying that an experienced programmer is likely missing something because there is a warning is rather suspect. The argument works great for the general case, because at the level of a whole program there is a lot more room to miss something.
But, if there is a reason not to turn off specific warnings for a short time, it isn't that there is still a "problem." For example, if you'll dealing with hashes, you'll get uninitialized errors in some types of things, but whether it's initialized might be besides the point. If it exists might really be what matters.
Adding extra code that isn't needed to get rid of the warning is at least as bad as turning off the warning where you know it isn't a problem, so judgement is required.
I think a good rule is, "if you fully understand why you're getting the warning, then it's your call if it should be on or off." If you don't know what the warning is, but just want it to shut up, then yeah, read the manual, fix the code, etc.
-- Snazzy tagline here
| [reply] |
|