Warnings and Strictures should only be used during development. They don't really serve a useful purpose in production code.

I totally and utterly disagree.

Warnings and strictures are there to catch and prevent errors during development and help you trace errors in production. Seeing that a previously warning free script all of a sudden starts generating warnings is sign of a serious bug that should be resolved immediately. Disabling warnings and strictures would mean that you never knew a bug existed.

Specifically disabling specific warnings or strictures for limited scopes of your code is perfectly ok. Turing off warnings and stricutres in code that was written with it (most of CPAN) is irresponsible and dangerous.

I have been witness to several sites exposing their DB access username/password once a fatal error occurs.

So because these sites did something foolish you advocate removing your ability to see that the program is doing something unexpected? That doesnt make sense to me.

In CGI, advertising there is a problem to the user, in such a way as to expose your security, is bad. If you have a site that throws up warnings and errors, then you have either not tested it properly or haven't coded to catch errors and deal with them well enough to (a) allow the user to know there has been a problem and apologise for the inconvience and (b) log and report the warnings/errors in a responsible manner.

Blindly assuming warnings and strictures are going to save you is not a good design of a CGI application. If a "warning free script" starts sprouting warnings in a live situation, then that strikes me as the code not having been tested for the environment it will be deployed in. Also I think you are referring to these messages inacurately. Warnings are just that, warnings. They *might* indicate there is a serious bug, but not necessarily. If a warning was to indicate a serious bug, why tell the user? Why just write it to the error log, that might not get looked at for days, weeks or longer. Don't rely on the user to tell you something has gone wrong.

If warnings and errors are continually being written to log files, then you are wasting resources in CPU, disc space and time. Reporting errors so that they can be resolved quickly, without causing the site to throw error reports at the user or worse continually timing out (due to too many warning messages being written to log files), is a much better way to maintain a healthy site.

I too wouldn't advocate turning off warnings and strictures in all your CPAN modules, however, the likelihood that the fault will lie there is low. I should have qualified the statement you highlighted from my original post though. I don't advocate using warnings and strictures in production CGI scripts. In non-CGI and development CGI I do, as this is where the users/programmers generally do need to see warnings/errors as they happen.

Flaws like exposing usernames/passwords might be rare, but they highlight that relying on warnings and strictures are not part of good CGI design. To the general user, the usefulness of M$'s blue screen of death is zilch. Web pages that act in a similar way do themselves no favours. It's why 404s (usually) return a nice error page, rather than system error messages telling you the file in your (now fully qualified) directory doesn't exist.

Don't get me wrong, warnings and strict are good things to use. But use them responsibly, not to do the work for you.

In the post I was replying to, the AM claimed that "not using strict/warnings/tainting are all bugs/security holes". My point was that warnings and strict are neither, as from a user perspective they don't need to know the specifics of an error, only to know you are dealing with it. Poor testing is a poor excuse for relying on the user to tell you of errors.

--
Barbie | Birmingham Perl Mongers | http://birmingham.pm.org/