From: Nick Ing-Simmons [mailto:[EMAIL PROTECTED]]
Paul Marquess [EMAIL PROTECTED] writes:
Good catch Nick.
Instead of completely backing out the defined $str or return change, if
you change it to
unless (defined $str) {
warnif('uninitialized', 'Use of Uninitialized value in
encode_utf8');
return;
}
that gives us the same warning behaviour as print/tr/etc, but more
importantly it also gives users of the module the ability to silence the
uninitalized warning in the same way they do with print/tr, thus:
use warnings;
...
{
no warnings 'uninitialized';
Encode::encode_utf8($x);
}
But surely the warning we get now is (as a core warning) already so
controlled ?
The warning can be controlled if you place a no warnings in the scope where the
warning is generated. In the case above, that is *inside* the encode_utf8 function.
The setting of the warnings pragma in the block that calls encode_utf8 function
doesn't leak into the Encode function.
That's where warnings::warnif comes in. It checks to see if the warning is enabled in
the calling module. This allows module authors to give users of their module the
control over what warnings are generated.
Without adding the warnif calls to the code, the only way you can silence the warning
is
{
local $^W = 0 ;
Encode::encode_utf8($x);
}
and that only works if the function being called isn't itself under the control of the
warnings pragma. So for example
sub xxx
{
use warnings ;
my $a =~ tr/A/a/;
}
{
local $^W = 0 ;
xxx();
}
still generates the Use of uninitialized value warning.
I see that Encode does make use of the warnings pragma in places, so I'm not sure if
the local $^W = 0 trick can be used with it.
And can we not enhance the message generator to fish the name out
of somewhere so that is says Use of undefined in subroutine encode_utf8
rather than just subroutine entry ?
That would be worth doing regardless.
Paul
