On 2010.6.8 1:15 AM, Maik Hentsche via RT wrote:
Show quoted text> Test::Harness always sets the -w switch for perl unconditionally. Since
> Test::Harness is used by ExtUtils::MakeMaker and in turn by
> Module::Install for make test. Both will output bogus warnings in
> testing because the programmer can not overwrite this warning decision.
> This is especially annoying for "uninitialized" warnings.
>
> Thus, I suggest removing the "-w" switch from Test::Harness and let the
> developer decide whether warnings are wanted or not.
Thank you for sending in this suggestion.
-w has been the default for Test::Harness since it was introduced 16 years
ago. It would break a lot of tests which check for the existence or
non-existence of warnings. Its also a good default (see argument below),
especially for tests, and worth having to quiet the occasional overzealous
warning. It ain't likely to change, sorry.
A simple work around is this:
BEGIN { $^W = 0 }
or if the "bogus" warnings are in your test script:
no warnings 'uninitialized';
If you want to nuke all warnings, overriding even "use warnings" you can put
-X in the #! line and Test::Harness will honor it.
Finally, Test::Harness has the $switches global (and the undocumented
HARNESS_PERL_SWITCHES) and TAP::Harness has the "switches" option to alter the
default switches.
So you have options.
I would strongly recommend rather than suppress these warnings during testing
to actually fix them. First, while uninitialized warnings may be annoying,
you can't tell an expected uninitialized value from an unexpected one. If you
ignore uninitialized warnings it becomes very difficult to know when your
program has a subtle data error.
Second is the "one broken window" psychological problem. Once one warning is
acceptable, two is very easy. And then three and four and soon nobody is
paying attention to the warnings any more. This is both because of a
deadening effect, warnings become "normal", and because there's so many
"expected" warnings to track that it becomes hard to see the unexpected ones.
This is particularly distressing to new users and programmers coming into the
project as they must learn, usually ad hoc, which warnings are "ok". It is a
less severe, but more insidious, version of the "expected failure" as in "oh,
these tests always fail, don't worry about it".
Finally, code, especially libraries, which habitually spit out warnings are
impolite. If I have warning-free code, with warnings turned on, and use a
function with "expected warnings" it clutters up my code and my logs. I
inherit the warnings and must deal with them by locally turning off warnings.
Get enough 3rd party functions that habitually throw warnings and you wind up
turning warnings off entirely.
--
The mind is a terrible thing,
and it must be stopped.
