It really depends on the condition that the warning/error is catching.

For "low fuel", a dashboard light is better than switching off the engine. For "driver has fallen asleep with foot on the accelerator pedal", stopping the car might be a better solution.

If an undef in a variable would led you to deleting every row in a database table, it might be better for the uninitialized warning to be fatal.

Whether a warning can be detected at compile time is another important consideration. Having an unimportant condition cause a long-running process to crash can be awful, but if the same warning prevented it from being started, that would be OK, because it could be fixed straight away. For example, the "void" and "once" warnings categories are detected at compile time, while "numeric" and "uninitialized" are detected at run time.

For "driver has fallen asleep with foot on the accelerator pedal", stopping the car might be a better solution.

Not really. Wind down the window; play music loud; vibrate the seat or steering wheel; a strident bonging sound; all would be preferable to bringing the car to a sudden halt in the middle of a motorway.

If an undef in a variable would led you to deleting every row in a database table, it might be better for the uninitialized warning to be fatal.

It's hard for me to imagine how that would occur, but if it is a possibility, then I might resort to use warnings FATAL => 'uninitialized'; within some limited scope(s); but never FATAL => 'all'.

I routinely eliminate/guard against all warnings in my code as I go along; but when they do occur unexpectedly, seeing whether they are 1-offs or repeated, whether once they start, they persist or are occasional transients; and where the code goes and what other knock-on warnings arise as a result; all assist in the postmortem of working out what went wrong and what to do about it.

Even more so when, for example, you get an unhandled transient warning induced by bad data in a long-running, unattended process.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

If an undef in a variable would led you to deleting every row in a database table, it might be better for the uninitialized warning to be fatal.

This is why you put in thorough sanity checks before doing something so destructive:

if (defined $thing) {
    destroy_database($thing);
} else {
    do_something_else();
}
[download]

undef has well-defined semantics in Perl (empty or zero), which are very useful in most cases. You should know when your code may do something catastrophic, and be very careful then, but that's no reason to be paranoid everywhere.

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.

There is a difference between warnings and errors; and treating them both the same is like treating gangrene and a paper cut equally with amputation.

It's worse than that. p5p is cautious about adding exceptions for previously working code, at least without requiring users to use the feature pragma or an explicit version number. p5p is much more willing to add warnings where they did not exist before.

Code which unilaterally converts warnings to exceptions could find itself dying of exceptions when run on a new release of Perl, whereas code which enables warnings would (merely) add to the warning logs. That's a risk I'm not willing to take for most code.

Edit to add: I know BuK already knows everything I wrote, but his message was the best place to put this reminder for everyone else.

Edit to add: I know BuK already knows everything I wrote,

Knowing (somewhere, deep down; maybe) and having thought about the consequences are two different things.

I stand as a one of those gratefully reminded. Thank you.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.