Is there a more graceful way of doing this other than disabling warnings for that chunk - through __WARN__ - as I have done there?
I think your introduction of _unset_sig_warn() was misguided.
Why not simply use lexical warnings? (see: perllexwarn).
You typically switch off specific warnings in the smallest
possible lexical scope.
For example:
use strict;
use warnings;
my $z; # $z contains undef
if ($z eq "") { # oops, Use of uninitialized value $z in string eq
print "1. string is empty (with warnings)\n";
}
# Switch off the specific uninitialized warning in a lexical scope.
{
no warnings 'uninitialized';
if ($z eq "") { # no warning this time
print "2. string is empty (with no warnings)\n";
}
}
# warnings switched back on at end of scope
If there is a reason you cannot use this technique
in your inherited CPAN module please let us know.
| [reply] [d/l] [select] |
| [reply] |
> To get out of the Use of uninitialized value I started adding the $blah AND $blah ... ... which is when I got totally caught up in this.
IMHO thats wrong!
Initialize a value, preferably at the moment where those variables are declared.
Either "" or 0 depending on the way it's used in the line where you got the warning from.
E.g.
DB<115> use warnings; print " $z bla"
Use of uninitialized value $z in concatenation (.) or string at (eval
+39)[multi_perl5db.pl:644] line 2.
Most likely means that $z is a string, so change my $z to my $z=""
| [reply] [d/l] [select] |
I subscribe to this opinion as well.
To me, undef could mean a couple of things, depending on context:
- if a function returns it, the function means to tell me
- there's nothing more to tell you (e.g. when <$filehandle> has read the last line of the file, or when each %hash has returned the last key/value pair of the hash)
- something went wrong (e.g. "you asked me to list your appointments on Feb 30th, but I couldn't find that date in my calendar?")
- it wants to return a false value, where 0 or "" don't cut it (e.g. if you use some module to log in to your Amazon account and get the number of items on your wish list, it would be bogus for $amazon->items_on_wish_list to return 0 when $amazon->log_in(user => "muba", password => "soopr sekret!111") failed. 0 here would mean that my wish list is empty, whereas undef would mean "failed to fetch wish list")
- it pulled its return value from some external source (a JSON object, a database record, whatever) and needs a way to represent the external source's notion of null or whatayamaycallit)
- if I set a value to undef manually, I could do that because
What all of these reasons have in common, is that they essentially mean to represent mu.
If asked the question, "did you stop beating your wife?" then the answer "no" would imply that you still beat your wife. "Yes" doesn't cut it either, because it directly means that you used to beat her. But "mu" or "undef" would mean, "the question does not apply, I have never beaten her."
Therefore, I think that if you're about to do something with a variable (print it, interpolate it, do arithmetic operations with it, throw it against a wall, feed it to your dog), you should either make sure it isn't undef, or explicitly check for its definedness.
| [reply] [d/l] [select] |
my( $is_success, $return_val ) = this_function_might_return_mu();
But I see the obvious merit in returning undef - Something I intend to use in the future.
| [reply] [d/l] |
my $data ;
$data = ref($hash) eq 'HASH' ? $$hash{$name} : $hash ;
$data = $$data{CONTENT} if ref($data) eq 'HASH' ;
There is some circular reference also ... Guess I have to stick with catching __WARN__ | [reply] [d/l] |
I don't get a warning, so whats the problem?
| [reply] |
This code feels... itchy... to me. No offense ;)
Let's assume ref($hash) ne 'HASH', then $data = $hash, so ref($data) will never eq 'HASH', so that statement modifier on the last line is redundant in this case.
However, say ref($hash) eq 'HASH' is true, then $data = $$hash{$name}, and then $data = $$data{CONTENT} provided that $$hash{$name} is a hashref. For the sake of argument, let's say it isn't. Then $data will still be $$hash{$name}. Is that how it's supposed to work?
| [reply] [d/l] [select] |