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

[bofh_of_oz]

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).

[tlm]

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.

[bofh_of_oz]

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...

[Anonymous Monk]

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'.

[Limbic~Region]

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"