Re^2: Four annoying warnings

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.

Comment on Re^2: Four annoying warnings Select or Download Code

Replies are listed 'Best First'.
Re^3: Four annoying warnings (undef, refs) by tye (Sage) on Dec 12, 2012 at 16:37 UTC
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. - tye	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Four annoying warnings (undef, refs)
by tye (Sage) on Dec 12, 2012 at 16:37 UTC

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.

- tye

[reply]
[d/l]
[select]