Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^2: On Commenting Out 'use strict;'

by bofh_of_oz (Hermit)
on Aug 11, 2005 at 12:49 UTC ( [id://482936]=note: print w/replies, xml ) Need Help??


in reply to Re: On Commenting Out 'use strict;'
in thread On Commenting Out 'use strict;'

I would say that IMHO there are no trivial error messages: if compiler/interpreter complains, it is an error and must be fixed before sending code into production. Warnings can be commented out until all the errors are resolved; then, if you have time, deal with small things... but errors should be fixed.

As for our own error reporting - that's for the "logical" errors that Perl cannot catch but they still lead to wrong results - yes, most definitely. That's the second thing I tend to do (after coding the functionality).

--------------------------------
An idea is not responsible for the people who believe in it...

Replies are listed 'Best First'.
Re^3: On Commenting Out 'use strict;'
by tlm (Prior) on Aug 11, 2005 at 13:19 UTC

    I would say that IMHO there are no trivial error messages...

    Step back for a second. What you just wrote is about as defensible as the statement "IMHO there are no bugs."

    You want to see a trivial error message? Here, stick this anywhere in your code:

    die "I'm sooo not trivial!";
    A trivial error message or warning is nothing more than a design bug.

    Consider for example the warning

    Useless use of a constant in void context
    If you read the follow-ups to Why no warnings for 1 in void context?, you'll learn that perl has a special check so that this warning is omitted if the constant is 1 or 0, or a few other esoteric values. I don't know about Larry (or whoever coded that particular bit of perl), but I'm sure that if it had been me who coded that I would have missed adding these checks first time around, and only figured that I needed them after seeing how perfectly sound code was suddenly spitting useless warnings. I.e. there is no a priori guarantee that warnings are non-trivial; this is only a function of the skill of the programmer.

    My point is that, the flip-side to the OPs observation is the burden on programmers to make their error messages non-trivial, that this also requires work, and that the more skilled you are as a programmer in keeping your error messages non-trivial, the less likely it is that users will ignore them.

    the lowliest monk

      I feel I need to clarify my statement.

      When I say "There are no trivial error messages", I mean exactly that: there are no trivial error messages that Perl gives you. I do not consider the error messages produced by or die "blah blah blah" constructs as I consider them a representation of the program logic created by a programmer who (supposedly) knows what (s)he is doing. I also specifically said that I do not talk about warnings - those are _not_ error messages, they are just that - warnings...

      What I mean is when you write a script, and run it, and Perl gives you an error message, it means there is a problem that must be fixed or the script won't run (properly|at all). It's similar to writing a resume and not doing a spell check - if it contains misspellings, it will most likely be rejected outright. Unusual grammar constructs etc. can be overlooked - spelling errors are not. Same thing in coding - warnings can be overlooked, errors should not be.

      Just my 2 cents...

      --------------------------------
      An idea is not responsible for the people who believe in it...

        bofh_of_oz,
        Ok, I am a big advocator of using the strict and warnings pragmas as well as the diagnostics when necessary. With that said, how does a novice distinguish between a warning an error. Consider the following 1 liner
        perl -e "my $foo; my $bar = 3; $bar += $foo; print $bar" versus perl -Mwarnings -e "my $foo; my $bar = 3; $bar += $foo; print $bar"
        Perl's DWYMery silently converts undef to 0 for us without warnings producing the correct answer in both cases but with warnings it warns me of a potential problem. In fact, Perl isn't consistent in its warnings:
        # ++ is a short cut for $foo = $foo + 1 perl -Mwarnings -e "my $foo; $foo++; print $foo"

        Cheers - L~R

        What I mean is when you write a script, and run it, and Perl gives you an error message, it means there is a problem that must be fixed or the script won't run (properly|at all).
        Well, you are right in the sense that whenever Perl gives an error message, it stop execution/compilation. But there are many cases where Perl could have continued - and everything would worked as planned. Triple so in the case of warnings. Consider this program:
        use strict; while ($str = <>) { print lc $str; }
        It won't run, because Perl refuses it to compile. But if you remove the generation of the error message and its subsequent refusal to continue, for instance, by removing the 'use strict;' line, out outcommenting the relevant part in the source of perl, the program runs fine. There's an error message, but the program doesn't contain bugs.

        And then there are the numerous, pointless, warning messages:

        print (1) qw /#/ $foo + $bar
        which you see written as:
        print +(1) qw /\#/ ($foo || 0) + ($bar || 0)
        just to please 'use warnings'.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2024-03-29 12:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found