Because of autovivification-related bugs, I got into the habit of using defined instead of exists to determine whether a hash contains a certain key.

Back up one second there. exists exists in Perl's vocabulary for the purpose of determining if a hash element exists. defined doesn't tell you whether or not it exists, it tells you whether or not it has a value set.

The autovivication problem doesn't occur when you do this:

print "Exists!\n" if exists $hash{somekey};
[download]

It occurs when you do something like this:

my %hash = ( Key1 => { john => 1, pete => 2 },
             Key2 => { frank => 3, howard => 4 } );
print "ted Exists!\n" if exists $hash{Key7}{ted};
print "Key7 now exists!\n" if exists $hash{Key7};
[download]

The difference is that in order to test for the existance of ted as an element referenced by $hash{Key7} Perl has to autovivify Key7. That is a big difference. The moral of the story is to always check for the existance of the higher level (if you cannot assume it exists) before checking for the existance of the lower level. But that's no reason to resort to using defined to do exists job, and in fact, using defined in this sort of context isn't going to prevent autovivication since testing for ted's value still requires that Key7 spring into existance silently.

To that point, the "autovivication bugs" issue is not a bug in exists, it's a type of bug that programmers encounter by not understanding how autovivication works.

I did not mean to imply that exists causes autovivification. What I was trying to get at is that autovivification has made me wary of keys that exist spuriously. These can occur in a number of ways, and I'd rather avoid the issue altogether by using defined instead of exists as a matter of policy.

The point is not whether spurious autovivification can be avoided (it is not hard to do so). The point is that I want to write my code so that, if I find myself debugging it weeks or months later, I don't have to worry over every exists expression that I run across. In other words, the possibility of unintended autovivification renders exists suspect in my eyes, and I'd rather deal with such suspicions as little as possible. A consequence of this is that I don't use undef as a hash value unless it is really necessary, or in very narrowly circumscribed blocks of code, in which one can tell at a glance that unintended autovivification is not a problem. It's all defensive programming, like avoiding globals, for example.

the lowliest monk

But defined doesn't do anything to prevent autovivification either. Look at this:

my %hash = ( Key1 => { john => 1, pete => 2 },
             Key2 => { frank => 3, howard => 4 } );
print "Exists!\n" if defined $hash{Key7}{ted};
print "Key7 exists!\n" if exists $hash{Key7};
[download]

Here you're testing the definedness of a key that doesn't exist: $hash{Key7}{ted}, and then you're going to check to see if $hash{Key7} autovivified. Guess what? It did, just the same as when we used exists to check for the existance of $hash{Key7}{ted}. The same conditions that will cause exists to autovivify a hash element will also cause defined to autovivify a hash element. exists doesn't have any more possibility to do that than any other function.




Dave