Re: Four annoying warnings

[Anonymous Monk]

in reply to Four annoying warnings

If you did the right thing and were fully aware of everything you were doing, warnings would be unnecessary. But brains fart regularly. And when they do, you might not even be aware of it were it not for those warnings ... and that puts the risks right off the scale.

[dsheroh]

That applies to many warnings, yes... but not necessarily to those listed here. Personally, I can't easily recall warnings 'undef' ever having caught an actual problem in my code¹, but it's constantly complaining about cases where nothing is wrong aside from my not having bothered to add an explicit default-to-zero or test-for-defined whose sole purpose is to shut warnings 'undef' up.

¹ Which is not to say that it hasn't ever caught an actual problem for me. I'm sure it has done so on at least several occasions. But they're so rare that I can't think of any offhand.

[tye]

It depends how you code. It is certainly easy to code in a way where 'undef' warnings are both common and uninteresting. And 'undef' warnings are easily the ones that are mostly likely to be annoyingly common and annoyingly uninteresting.

But I usually code in a way where 'undef' warnings are much less common and much more likely to indicate a real mistake. I only rarely find myself disabling 'undef' warnings.

My biggest disagreement with the original posting is that I've never seen "isn't numeric" be a warning that I would just ignore. That warning is almost always an indication of a serious problem when I run into it.

I've only once been bitten by a bug caused by a reference being usable as a number without warning. But I agree that this could be extremely useful to be able to flag such things. I certainly want to be able to do $ref1 == $ref2. I very, very rarely even want to do things like pack "p", $ref. And 0+$ref, especially with a literal zero like that, should probably never cause a warning. But any other uses of the numeric value from a reference should generate a warning. Unfortunately, that looks rather difficult to implement in Perl, at least in some respects. Maybe not so bad if we just add a flag to scalars.

Worse was when read-only access of undef as a reference could be fatal! But maybe all of those cases have now been fixed. I've always had a hard time remembering exactly how to reproduce this failure but gave up trying to reproduce it on a modern Perl today. I'm hopeful that this just isn't a problem in modern Perls.