Reliably checking that something doesn't exist

ritontor has asked for the wisdom of the Perl Monks concerning the following question:

I'm currently working on a little snippet of code, and i've hit this exceedingly weird problem. Here's a basic outline of what it's doing:

if (!(defined( $FDomainName->{ WEBFWD } ) ) ) {
      if ( defined( $FDomainName->{ DocumentRoot } ) ) {
            $FDomainName->{ WEBSPACE } = "TRUE";
      }
}
[download]

The program essentially accepts a line of data on stdin (a domain name) and then returns details to stdout. Pretty simple stuff. It's a WHILE (<STDIN>) sorta deal, so one can keep plugging domains in until you get bored.

Now, there have been many cases when executing this code that even in the case where $FDomainName->{ WEBFWD } absolutely positively DOES definately have something in it - a URL, to be precise - that $FDomainName->{ WEBSPACE } still ends up equalling "TRUE". Can anyone shed any light on this phenomenon? To make matters worse, it's intermittantly failing - most of the time, when $FDomainName->{ WEBFWD } has its URL, then WEBSPACE doesn't get set to "TRUE". Oh, and this is the only place where the WEBSPACE hash thing can ever get set throughout the whole program.

I'm really scratching my head over this. I *know* that each and every time i run the code and the check fails (or succeeds, depending on how you want to look at it) that there is definately a string in the checked variable, cause i've been printing it for debug purposes, yet still it's failing to work in the prescribed manner. I bet i'm doing something stupidly wrong :) Let me guess, an if (!( $variable )) { foo } type check is unreliable, and i should know better? :)

Comment on Reliably checking that something doesn't exist Select or Download Code

Replies are listed 'Best First'.
(Ovid) Re: Reliably checking that something doesn't exist by Ovid (Cardinal) on Nov 26, 2001 at 21:31 UTC
Actually, frankus is correct that you typically wants exists instead of defined when testing for the existence of a hash or array element. However, if you are truly needing defined, then your code is correct. As for the code you have shown us, I think we need more code to figure out what's wrong. Oh, and since the second if is dependant on the first, why not combine them? It's clearer to read (I left defined in on the off chance that this is really what you need): `if ( ! defined $FDomainName->{ WEBFWD } and defined $FDomainName->{ Do +cumentRoot } ) { $FDomainName->{ WEBSPACE } = "TRUE"; }` [download] Cheers, Ovid Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.	[reply] [d/l]
Re: Reliably checking that something doesn't exist by frankus (Priest) on Nov 26, 2001 at 20:51 UTC
use exists instead of defined? `unless (exists($FDomainName->{WEBFWD}) ) { $FDomainName->{WEBSPACE}= 'TRUE' if exist($FDomainName->{DocumentR +oot}) }` [download] -- Brother Frankus. ¤	[reply] [d/l]
Re: Re: Reliably checking that something doesn't exist by ritontor (Acolyte) on Nov 26, 2001 at 21:09 UTC
Nope, still does the same thing, sets `$FDomainName->{WEBSPACE}= 'TRUE'`. I'm still printing `$FDomainName->{WEBFWD}` and it still has its URL in it :) Just for further clarification, `if ( $FDomainName->{ WEBSPACE } =~ /TRUE/ ) { foo }` is how i'm checking to see if it's been set.	[reply] [d/l] [select]
Re: Re: Re: Reliably checking that something doesn't exist by frankus (Priest) on Nov 26, 2001 at 21:20 UTC
hmm works for me: `#!/usr/bin/perl -w use strict; use Data::Dumper; $_ = { foo=>1, bar=>2, baz=>3}; print Dumper $_; print "Wahey!\n" if exists($_->{foo})` [download] is the variable being declared inside the loop, or outside in which case it may be retaining values. -- Brother Frankus. ¤	[reply] [d/l]
Re: Reliably checking that something doesn't exist by Fastolfe (Vicar) on Nov 27, 2001 at 00:23 UTC
Use Debugging 101 stuff: add some print statements in there that record each step of the loop, and the values of each variable during each iteration of that loop. Check the output to be sure your assumptions are being satisfied. Your code looks fine, so the problem is probably outside of what you've shown us. This means you're assuming something else is working when it probably isn't.	[reply]