Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: Difference Between use warnings and use warnings FATAL => 'all'

by BrowserUk (Patriarch)
on Dec 27, 2013 at 12:39 UTC ( #1068508=note: print w/replies, xml ) Need Help??


in reply to Difference Between use warnings and use warnings FATAL => 'all'

I've always thought of fatal warnings being akin to your car engine cutting out and the brakes being applied automatically when the fuel-low warning light comes on.

The warning light serves the purpose of giving you a chance to avoid getting stranded.

Making warnings fatal definitely strands you; and could be literally fatal if you are in the outside lane at speed when the fuel-low light comes on.

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.

The former might lead to the latter eventually; but it is a rare occurrence. Another instance of dogma trumping logic.


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.
  • Comment on Re: Difference Between use warnings and use warnings FATAL => 'all'

Replies are listed 'Best First'.
Re^2: Difference Between use warnings and use warnings FATAL => 'all'
by tobyink (Canon) on Dec 27, 2013 at 14:10 UTC

    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.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
      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(); }
      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.
Re^2: Difference Between use warnings and use warnings FATAL => 'all'
by marinersk (Priest) on Dec 27, 2013 at 14:07 UTC

    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.

Re^2: Difference Between use warnings and use warnings FATAL => 'all'
by chromatic (Archbishop) on Dec 28, 2013 at 20:29 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1068508]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (3)
As of 2022-01-22 19:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (63 votes). Check out past polls.

    Notices?