Quoth a (highly readworthy) Henry Baker rant at the Risks Digest,

I asked the CEO of a high-tech company whose products are used by a large fraction of you about this issue and why no one was willing to spend any money or effort to fix these problems, and his response was that "the records of our customer service department show very few complaints about software crashes due to buffer overflows and the like". Of course not, you idiot! The software developers turned off all the checks so they wouldn't be bugged by the customer service department!

Of course this relates to buffer overflows, but I see strict, warnings and taint mode as the closest equivalents when working with Perl. There is definitely no excuse ever to turn them off for any nontrivial script in my very strong opinion. Production code should not violate any of these constraints when running smoothly. Any errors you then get indicate a problem you aren't catching properly.

I'd rather my users complain because scripts produce spurious warnings or even bail out as opposed to finding they've been silently throwing sand between the gears. There is no telling how much and how critical data a program that keeps running on bad input is going to mess with.

My policy is that any production code should never try to recover from faults that were not specifically anticipated and error handled. If something looks wrong, even if it's minor, I have my code die screaming. I'd rather look stupid for a few minutes and have to fix a minor oops when the script sticks its tongue at me than have to fix or, horrors, write off corrupt data after the fact.

Makeshifts last the longest.