That was a dramatic way to put it, but this does largely sum up why I prefer to use warnings during development but drop it when the code moves to production.

The users should not have to see Perl underwear, and are not expected to understand what they see anyway. But a developer should code until the warnings subside for all test cases, which should be fairly encompasing if you are using Test-Driven Development.

Turning the warnings fatal is in interesting escalation of the issue. I'm not sure I see the point for the vast majority of development, but then I trust that if I tell my developers to code with warnings on until none appear that they will do so.

I suppose I could imagine a corner case where recovery from bade code might be a huge inconvenience or take an inordinate amount of time. If the routine, for example, might risk deleting every row in a table and that would halt work by lots of developers or the restore might take a huge amount of time. But there are usually other ways to mitigate these kinds of problems, so I'm still not sure I buy into this approach to solve this kind of problem.

I could see one developer turning warnings fatal because they are the type who wants to fix the warning as soon as they bump into it, so this makes a one-line way to force the code to stop immediately so the errant code can be adjusted. And then perhaps forgetting to remove it before checking the code back in to source control. Such a situation could cause another developer to suddenly start seeing lots of warnings->FATAL references, I suppose.

I would be inclined to make checking for that a step during the process by which code is promoted into production. Especially since I am a proponent of the no-warnings-in-production philosophy anyway, this would automatically be caught in that net.

But I find it terribly rude to force end users to see error messages which are not generated in a context they are expected to understand. They are not likely to be computer scientists or software engineers, and may not even like the "{explitive deleted} computer" in the first place. The last thing we need to be doing is showing them error messages they cannot hope to understand, did not cause, and which were generally designed for us computer geeks to see.

Have mercy on the user. Ultimately, they pay our salary.