Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Turn off warnings, diagnostics?

by Anonymous Monk
on Nov 07, 2012 at 15:46 UTC ( #1002685=perlquestion: print w/ replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks,

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

What happens when both are turned on (uncommented)? Does it mean error messages get displayed on the webpage?

Thanks in anticipation!

Comment on Turn off warnings, diagnostics?
Re: Turn off warnings, diagnostics?
by choroba (Abbot) on Nov 07, 2012 at 16:04 UTC
    Usually, warnings and error messages go to standard error (STDERR). The webpage, on the other hand, is taken from standard output (STDOUT). STDERR is usually redirected to a log rather than the webpage.
    لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
Re: Turn off warnings, diagnostics?
by Tanktalus (Canon) on Nov 07, 2012 at 16:51 UTC

    Personally, I have

    use warnings FATAL => 'all';
    in my production scripts. But I'm kind of a masochist that way. Mind you, near the top level I also run everything in a big eval block (ok, it's actually a small block that calls the main code) so that I can log/trace the errors, too.

    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 }
    And thus any warnings that my production code still emits is actually against the design, or at least not yet evaluated, and only an accident would lead to good behaviour if I had them removed.

    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.

Re: Turn off warnings, diagnostics?
by fishmonger (Pilgrim) on Nov 07, 2012 at 17:28 UTC
    IMO, turning of warnings is the wrong approach. Instead, it would be better to log all errors and warnings.
Re: Turn off warnings, diagnostics?
by davido (Archbishop) on Nov 07, 2012 at 17:52 UTC

    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.


Re: Turn off warnings, diagnostics? (maybe, yes)
by tye (Cardinal) on Nov 07, 2012 at 18:33 UTC

    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.

    - tye        

Re: Turn off warnings, diagnostics?
by kcott (Abbot) on Nov 07, 2012 at 18:35 UTC
    "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 ...

    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.

    -- Ken

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1002685]
Approved by Corion
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (7)
As of 2014-07-25 04:37 GMT
Find Nodes?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:

    Results (167 votes), past polls