Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re^2: Modifying Arrays passed by reference to subroutine

by akho (Hermit)
on Jun 09, 2009 at 07:13 UTC ( #769802=note: print w/replies, xml ) Need Help??

in reply to Re: Modifying Arrays passed by reference to subroutine
in thread Modifying Arrays passed by reference to subroutine

perllexwarn explains why use warnings is better than -w. use warnings FATAL => 'all' is even better than use warnings. And if you expect warnings to do parameter validation for you, you should be extra careful. It's usually easier to check them.

Replies are listed 'Best First'.
Re^3: Modifying Arrays passed by reference to subroutine
by Marshall (Abbot) on Jun 09, 2009 at 10:47 UTC
    This reference to perllexwar basically says that the problem can be that you turn warnings ON for more than maybe you want to.

    I figure that more aggressive warnings are usually better than less aggressive. If you get warnings that you decide are not warranted, then you can "crank down the warning level" for that segment of code, but usually (in my opinion) that's the wrong thing to do unless you are extremely clear about why you are going that.

    As far as parm validation goes, there is a whole bunch that didn't get talked about for this code example....use of prototypes in Perl functions, etc. In this case the issue was defined or not which is different than say param #3 should be between 4 and 12.

    In any event, I think that it is wrong to return silently when the sub fails.

    Update: In any event, I think that it is wrong to silently return a valid return value when the sub fails.

      My point was that sometimes undef may not lead to a warning, but your sub won't do what you expect it to. Lack of proper sub signatures is sometimes annoying.

      perllexwarn also talks about code in modules; -w enables warnings anywhere, so other people's code (i.e. those people who knew what they were doing and turned off warnings for relevant parts of their code) will throw warnings at you. It may be a lot of warnings.

      "Throwing a warning" is exactly equivalent to "returning useless stuff silently" in most scenarios; warnings are written to stderr, which is not available for a lot of programs. And even if it is available — most end users just ignore it. If your code is potentially destructive (and what code isn't) you should die in unexpected situations, not issue a warning.

      Also: use warnings FATAL => 'all' is much more aggressive than -w.

        I think we are pretty close to saying the same thing. You are correct that "undef" may not lead to a warning. Also correct that -w on the shebang line may cause other warnings..

        I have found that the simple: use warnings or -w is about the right idea and that FATAL would be wrong...This is ok for testing, but once an application is "out in the wild", I don't think so.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://769802]
and the monks are chillaxin'...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (10)
As of 2018-06-25 20:25 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (128 votes). Check out past polls.