in reply to Do people find warning for undef with string compare useful?

For me the warning is useful.

If a string is missing a value, that is an indication of a potential bug. The warning tells me that what I expected is not what I got. Either I have over looked someplace where a default should be set, or the incoming data is deficient (the User didn't fill in a field on the form, the database is missing a value, etc.) As a matter of defensive programming, I want to know that a value was missing, so I can run the bug to earth and fix it. And also determine why my test harness missed it. (The Spec said that User-ID-Alias is a required field, so why is it blank in the DB?)

Now, whether the end-user of my code sees the warning is another matter. I write errors and warning to logs that I can check later. For code going into production for the first time, the first few days of those logs can be very enlightening (or horrifying....).

----
I Go Back to Sleep, Now.

OGB

  • Comment on Re: Do people find warning for undef with string compare useful?

Replies are listed 'Best First'.
Re^2: Do people find warning for undef with string compare useful?
by perl-diddler (Chaplain) on Jun 01, 2013 at 01:56 UTC
    Now you realize, I mentioned only the "eq" and "ne" operators (cuz or/and/not already work on undef w/no warning).
    I'm not talking concatenation, or where you print it out.
    But specifically where you are testing the value against something else.
    In that case, do you still think, that if you are doing a comparison on it, you wouldn't notice that "empty"(undef) is or is not equal to some other string?
    How do you see it different than "and" "or" and "not"...

    i.e.
    string1 or string2 = true if one of them has length>0 etc...
    but it doesn't warn you about undef.

    It sounds like you were thinking concatenation... mixing strings w/strings... but if you are comparing, aren't you already testing the value? i.e.:

    > perl -we 'use strict;use P; P ((undef and 1) ? "yes": "");' no > perl -we 'use strict;use P; P ((undef or "") ? "yes": "no");' no > perl -we 'use strict;use P; P ((undef xor "") ? "yes": "no");' no > perl -we 'use strict;use P; P ((undef eq "") ? "yes": "no");' Use of uninitialized value in string eq at -e line 1. yes perl -we 'use strict;use P; P ((undef and 1) ? "yes": "no");' no > perl -we 'use strict;use P; P ((undef and 1) ? "yes": "no");' no > perl -we 'use strict;use P; P ((2 or undef ) ? "yes": "no");' y +es > perl -we 'use strict;use P; P ((2 xor undef ) ? "yes": "no");' yes perl -we 'use strict;use P; P ((2 ne undef ) ? "yes": "no");' Use of uninitialized value in string ne at -e line 1. yes Ishtar:/tmp> perl -we 'use strict;use P; P ((undef xor undef ) ? "yes" +: "no");' no perl -we 'use strict;use P; P ((not undef xor not undef ) ? "yes": "n +o");' no etc....

    So you already have the ability to use defined/undefined as boolean states, why do you think a warning when using it with equality, (eq or ne), is useful?

    Note I'm not talking about undef==3, or 2>=undef... or even undef cmp undef... as all of those *expect* some type of ordering or value.

    But if something is eq or ne, doesn't.

    Limiting it to that and considering we are only asking if what is in "$a" is the same as what's in "$b" (or not the same)...

    You still think the warning for that specific case is more useful than not?