in reply to Re: Surprising result when using undef
in thread Surprising result when using undef

I think that you have a good understanding!

I'm not sure that it is 100% clear, but the // operator can be used like +=,*=, etc. I don't use any language other than Perl that has this operator. But this is a cool operator (added in Perl 5.10).

In my coding, the most common occurrence would be something like $token //= ''; after some regex that might fail (and hence yield an undef). This means: if $token is defined leave it alone. However if it is undefined, set it to the null string. I do that right after the regex. This prevents warnings in comparisons and other ugliness with the DBI later on.

In your code, perhaps:

$possibly_undefined_val_here //= 1; if ( $possibly_undefined_val_here == 0 ){} #now always defined
However as I think you see now, it is much better not to intentionally generate any undef value on your own. The equivalent thing to //= in Perl <5.10 requires an if statement. Numerous studies show that an "if" statement is at least 10x more likely to contain an error - no matter how simple appearing the "if" statement might look. Your woes are a case in point.

Update:
Since your code is obviously intended to have different behavior in the production mode vs the debug mode. One feature of Perl that perhaps you should be aware of is the constant pragma.

It is possible to write:

use constant DEBUG => 1; if (DEBUG) {}
If you change to: use constant DEBUG => 0; The if statements with DEBUG won't even be compiled! So there is no run-time penalty for code like that in the production version. By normal convention, constants are all CAPS although there is no language enforcement of that convention.