Personally, I have

use warnings FATAL => 'all';
[download]

What you do depends on your ideology here. Some people prefer to remove strict/warnings so that the code "just works". But I look at as "just works wrong". Sometimes it works right, but that's actually an accident more than by design. If I have a design point where I want no warnings for a piece of code, I create a block for it, and do something like this:

{
  # we actually want to treat undefs as empty strings, just easier tha
+t
  # way here.
  no warnings 'uninitialized';
  ... # code that might use undefs legitimately goes here
}
[download]

Your webpage question is already answered correctly: stderr doesn't go back to the web browser, it goes into the error log file of your web server.

Update: bad typo, thanks tye and AnomalousMonk.

I want the warnings. I just want to make sure they're directed somewhere useful, such as a log file.

In my opinion, tests should exercise the code to the degree that your own carp, croak, cluck, confess, die, and warn statements are executed. Tests should also check that there aren't any Perl-generated warnings and un-caught exceptions (deaths). In a real world the tests you write probably won't anticipate every possible way that a script might generate a warning. Those warnings (and even fatals) it does generate should be logged so that the maintainer can investigate and take corrective action.

Silencing all warnings so that they bother nobody might prevent the maintainer from even knowing there's an issue, and possibly a serious issue, that happens to only turn up out in the real world (ie, production). When I ship code I intend to also be the one maintaining it, and I want to have the ability to quickly ascertain there are no problems that I didn't anticipate. I wouldn't be as effective if I took the "bury my head in the sand" approach.

Diagnostics, on the other hand, have no place in production code. The warning itself is plenty, because in the event I am unfamiliar with a given warning I can always just dive into perldiag to read what it means.

"Do we turn both "use warnings" and "use diagnostics" OFF (by commenting them out) when the scripts go live?"

I would leave warnings for all environments (development, testing, production, etc.) but only use diagnostics in development (and only then if it's useful - it's certainly not required).

You can always retrieve the additional, verbose diagnostics text by searching perldiag or by running the splain utility.

While it's probably useful to see multiple lines of the form

Use of uninitialized value %s in concatenation (.) or string at ...
[download]

it's unlikely that you'll want see the following lengthy explanation of the warning more than once:

    (W uninitialized) An undefined value was used as if it were alread
+y
    defined.  It was interpreted as a "" or a 0, but maybe it was a mi
+stake.
    To suppress this warning assign a defined value to your variables.
    
    To help you figure out what was undefined, perl will try to tell y
+ou the
    name of the variable (if any) that was undefined. In some cases it
+ cannot
    do this, so it also tells you what operation you used the undefine
+d value
    in.  Note, however, that perl optimizes your program and the opera
+tion
    displayed in the warning may not necessarily appear literally in y
+our
    program.  For example, "that $foo" is usually optimized into "that
+ "
    . $foo, and the warning will refer to the concatenation (.) operat
+or,
    even though there is no . in your program.
[download]

I'd certainly turn off diagnostics. No point engaging all of that machinery in order to repeatedly verbosely explain every error and warning over and over again in the log.

I often support turning off warnings in many environments. But that depends on where the warnings go and are they likely to do any good. Warnings going to end-users is usually worse than a waste but also confusing and/or annoying.

Warnings going to the web server error log is often of little benefit but at little cost. There is a risk of a few pointless warnings getting logged at such a high frequency that they cause logs to fill disk or just make it unnecessarily cumbersome to notice, find, organize, or respond to more serious errors in the log.

There is also the chance for a developer to notice a warning in the log and from that figure out a subtle bug and fix it.

But I'd definitely not put "use warnings;" in your modules. Whether or not warnings are desirable depends on environment and so should be controlled by environment (with the caveat that there is a risk, small in my recent experience, of depending on somebody else's module that is sloppy about something that ultimately doesn't matter but that generates warnings when you enable them globally and yet you don't want to "fix" that warning because it isn't your module -- but a simple __WARN__ handler can usually easily plonk those).

Even more clear to me is that you should at least start with -w in the #!-line of your test scripts.

Whether to put -w in your web scripts is a harder call. Depends how likely developers are to make improvements due to those warnings ending up in the logs on that web server (I'd certainly turn on warnings in non-Production web servers and encourage routine review of web error logs by developers and QA) and how likely the warnings are to be voluminous enough to cause problems.