in reply to -w considered harmful

#!perl -w { local $^W = 0; }
Tada... Actually IIRC some feel that warnings is harmful. I never use it personally, for one it's not available everywhere, also it's not symmetric with -T; but then again strict isn't with -w. UPDATE: Although I believe the need to squelch warnings in this manner rather rare.

Basically I wanted to say that -w is evil. It causes code that shouldn't generate warnings to generate meaningless warnings that the author never intended it to.
Isn't that the point? Catch things you didn't intend?

--
perl -pew "s/\b;([mnst])/'$1/g"

Replies are listed 'Best First'.
Re: Re: -w considered harmful
by demerphq (Chancellor) on Sep 03, 2002 at 19:06 UTC
    Actually IIRC some feel that warnings is harmful.

    Ive heard an argument that is while practical still bogus. "Dont use warnings 'cause it isnt backwards compatible." Ok fine, thats a good argument, if you are writing a module that you want or need to have maximum coverage and _must_ be backwards compatible. But if your target enviornment supports warnings then the argument rapidly loses its merit.

    Also if you write modules (i write a lot, its part of my job) if you dont use warnings (and write for people using warnings) then you miss out on the power of warnings register. You remove the ability for the end user to specify their warning levels and you turn warnings on in places where the original coder might have specifically omitted them. Thats a PIA IMO.

    Isn't that the point? Catch things you didn't intend?

    Indeed, I do want things I didn't intend to do come to light. But I dont want to be told about warnings that I _specifically_ discounted. For instance Win32::EventLog works just fine. Use it under -w and it produces errors galore due to dynaloader (I think).

    Yves / DeMerphq
    ---
    Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)

      you turn warnings on in places where the original coder might have specifically omitted them.
      Did the original coder bother to local §^W = 0; or no warnings qw(whichever); ? If not, then I refuse to assume they specifically omitted warnings because they didn't. Code should always be made to run silently in the presence of enabled warnings; that doesn't necessitate "fixing" the cause of the warning, but it does necessitate being aware of a violation and disabling warnings as needed. -w is not harmful. People who don't anticipate it are.

      Makeshifts last the longest.

      Actually uh, the reason why I said IIRC and then later gave the spiel about backwards compatability is the argument I vaguely recall is *not* about backwards compatability, but rather flaws in the implementaion of warnings. But I may be auto-vivifying...

      --
      perl -pew "s/\b;([mnst])/'$1/g"

        Were you thinking of the emails linked from this?
      I agree that "use warnings"/"no warnings" is far better than the old -w switch. I switched to that as soon as it became available, and never looked back.
Re: Re: -w considered harmful
by demerphq (Chancellor) on Sep 04, 2002 at 09:38 UTC
    A second point is that you should review perllexwarn specifically the section titled What's wrong with -w and $^W as it will demonstrate scenarios where the local trick you showed above doesnt work. Localizing $^W is in no way a replacment for no/use warnings.

    Yves / DeMerphq
    ---
    Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)

      I didn't see anything there which doesn't follow from first principles (assuming one is aware of the delocalized nature of the checks done by perl). Not to say it isn't, umm, valid; it's just nothing new.

      --
      perl -pew "s/\b;([mnst])/'$1/g"

        Well the fact that
        local $^W=0;
        won't stop compile time errors wasn't immediately obvious to me... On reflection it made sense, but I imagine more than few reading this thread would be marginally suprised.

        Yves / DeMerphq
        ---
        Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)