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

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

Yes, I find it useful.

It is true that it is sometimes annoying in comparison tests where you just want to know, for example, if $a is equal to $b, not really caring whether one of the variable is undef, but the warning often tells you about a possible bug un your code or a possible anomaly in your data. It is good to have this information.

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 10:39 UTC
Laurent, you think that having warning on for $a eq $b, gives you more useful warnings than false ones? How would that not apply to: $a and $b and $c -- as a quick way to check for that all are defined -- but it gives you no warning if $b=undef vs. $b=''; I don't see how the eq case is any more helpful than the logical-only operators..? I just think of the amount of code out there that is written to avoid those warnings. Sure was a nice excuse for writing a replacement for Printf/sprintf/say that auto handles undef as args to a format by inserting 'undef' in the output - which I find alot less intrusive than a warning which, due to my own conventions, usually results in termination with traceback!... Don't many of us treat warnings as errors? I guess, personally, since my print's are all auto checked, I usually see undefs in debug and error statements -- though honestly, if someone gets a warning in their code over an undef, what that meand is that they didn't write code to check the value before making that comparison. How many such warnings are needed to get people to always program in checks where things possibly can be undef? Any value that can be undef -- will (eventually)...it's like a Murphism...;-) Relying on the warning to tell you that you left out a check doesn't seem real reliable, as there are alot of cases where no warning is given. But if people don't see that here, it sounds like we are stuck with it for the nonce....	[reply]
Re^3: Do people find warning for undef with string compare useful? by vsespb (Chaplain) on Jun 01, 2013 at 11:06 UTC
I don't see how the eq case is any more helpful than the logical-only operators..? Perhaps we should ask then why logical-only operators ignore undef, but not why other operators don't ignore it. I just think of the amount of code out there that is written to avoid those warnings. Really? a code to avoid warning and introduce bug: `$x = '' unless defined($x)` [download] a code to just avoid warning; `my $x = '';` [download] a code to avoid bug: `defined($x) or confess;` [download] So you see 1st case in your code? a code with bug: `mysub($user_data) { $user_$data->{invoice_number} ... } mysub({age => $user_age, inovice_number = $invoice_number}) # TYPO!` [download] a code which catches bug: `mysub($user_data) { defined($user_$data->{invoice_number}) or confess; $user_$data->{invoice_number} ... } mysub({age => $user_age, inovice_number = $invoice_number}) # TYPO!` [download]	[reply] [d/l] [select]
Re^4: Do people find warning for undef with string compare useful? by perl-diddler (Chaplain) on Jun 01, 2013 at 15:18 UTC
I think you are going off in left field. You asked: `Perhaps we should ask then why logical-only operators ignore undef, bu +t not why other operators don't ignore it. I just think of the amount of code out there that is written to av +oid those warnings.` [download] I think I made this clear earlier. It seems you are trying to change the nature of the discussion or are grasping at straws to prove some unknown point. You wouldn't turn off warnings for things that compare numbers or magnitude, as it is, inherently an error if you test 'undef' with an operator that compares magnitude. That TRULY, is an indication that you were expecting something that would have relative magnitude to something else, but instead, have something that is completely undefined. They are completely different. Comparing if two variables have the same value or are both uninitialized, isn't unreasonable. Since 'undef' is often returned for false and a non-zero length string that doesn't eval to 0 is returned for true, someone might simply want to compare the results of two tests to verify that both returned true or both returned false. Sure there are 100's of other ways to do it -- it was just a bit of a poll to see what people used it for and how it was more useful giving warnings as it does now, vs. acting like and/or/not/xor operators. You really didn't need to go into reasons why you should use the 'fields' and 'parents' pragma's... they have nothing to do with eq/ne as near as I can tell. I'm not sure what you are getting at in your telling me what is a bug and what is not -- or at least now how that is pertinent to the discussion. If you can't come up with any good reasons why it should be the way it is, that's fine. BTW -- IMO, "catching an error", and handling it -- ideally would involve invoking an alternate method to do what you were trying to do -- that's what humans do, unless they give up. Programming computers to continue in spite of errors, is really what is needed in today's SW, since all of it has errors. The next step in programming, is getting to programs that continue to run and do the right thing in the face of unexpected input -- or at least not to roll over and die. I have programs that collect status information, and if something is wrong, they take steps to fix it -- progressively, as well as send email at increasing intervals -- up to a day apart as long as the problem continues. More and more, I'm trying to build in redundancy and recovery into my programs, so that they won't harass me for little stuff. IMO, I tend to believe that the warnings produced for eq and ne aren't worth the problems they turn up, but that may be because I check for errors in others ways (if not in the first pass, eventually, because eventually, I am almost guaranteed to hit every trouble spot!) ;-)	[reply] [d/l]
Re^5: Do people find warning for undef with string compare useful? by vsespb (Chaplain) on Jun 01, 2013 at 15:28 UTC
Re^6: Do people find warning for undef with string compare useful? by perl-diddler (Chaplain) on Jun 02, 2013 at 05:24 UTC
Re^4: Do people find warning for undef with string compare useful? by perl-diddler (Chaplain) on Feb 11, 2014 at 21:47 UTC
Looking through old stuff... I saw `mysub($user_data) { $user_$data->{invoice_number} ... } mysub({age => $user_age, inovice_number = $invoice_number}) # TYPO!` [download] For most people the above would be caught by warnings+strict ... using an undeclared var, and/or only 1 use of the var. So never happens. Vs. here you say: a code to avoid bug: `defined($x) or confess;` [download] --- A program that dies unexpected has a bug. You didn't avoid a bug, but caught it and displayed it to the user. I guess in my programs, I rely on "undef" as a valid and useful value to mean something that isn't initialized yet and/or has not been assigned a value yet.. Example -- in a web-reading program, I had a value $p->{content}, that kept coming back "undef" after I got the content back from an html library. The call returned '0', to indicate it had succeeded in querying the server, but somewhere, it set some error value to '404' (that I couldn't easily find in the documentation) -- but it was then I realized, that 'content' was undef not due to any bug -- but because that's is what was returned from the website! Undefined/uninitialized content. Once I figured that out, I could handle it as some sort of read error and retry or ignore the call later. I think I eventually found the place for the error to be returned -- in an 'async-handler' call to an error routine. Not what I was expecting. In the above -- if I was checking if a mirror of the site was the same as another, comparing 'undef' against 'undef' would be a desirable operation -- it means both didn't return an object for 'something' (providing it is only a few objects). If it returns randomly or too often, something else may be wrong. (unlikely anyone reads these old replies -- too bad there's not a notification to people when someone has replied to one of their messages, ..vs. the current method of looking at all your posts and going through them 1-by-1 and looking to see if there are new responses... ;^/...)	[reply] [d/l] [select]
Re^3: Do people find warning for undef with string compare useful? by Laurent_R (Canon) on Jun 01, 2013 at 21:17 UTC
Laurent, you think that having warning on for $a eq $b, gives you more useful warnings than false ones? No. I think that those warnings are useless more often than useful. But sometimes they are useful. And I still prefer to have them when they are useful (maybe only one case out of ten) because they tell me I have a bug in my code or something wrong in my data, even if I have to deal with the more common useless cases. I had very recently a case where I wanted to remove duplicates from a sorted file. I wrote something like this: `my $previous_line; while (my $current_line = <$DATA>) { print $OUT $current_line unless $current_line eq $previous_line; $previous_line = $current_line; }` [download] And, of course I got a "false" warnings because $previous_line is not defined the first time through the loop. But, so what? How long does it take to change the first line of the code above to something like: `my $previous_line = "";` Ten seconds? I prefer to have these spurious warnings perhaps 9 times out of 10, because they tell me something really useful 1 time out of 10.	[reply] [d/l] [select]

In Section Seekers of Perl Wisdom