As an aside it strikes me that warn and die ought to return false.

Update: You could get the same effect as your code above without the sensitivity to warn's return by writing that as

for (1..5) {
    eval{
        do_foo() && do_bar()
    } 
    and print
    or warn $@; 
}
[download]

I would be interested to read you expound upon this aside.

My thinking was:

• As you say, who is ever going to test the results of die.
• But equally, where is the logic in testing the return of warn?

  If it fails, what are you going to do? warn about it.

  Maybe warn(...) or die(...); makes some sense; but then it would be better if warn itself died if it failed to warn. But what if die fails for teh same reason as warn. Should it warn> Or die? Or warn and die?

  Maybe it should send an SMS. But of course, that could fail also, and it would have to warn about that and then die :)

  That's mostly humour, but with the purpose of making a point.

For warn, a true return value enables structures such as warn "Loop failure\n" and next if $_ eq "bad"; that I feel (YMMV) are quite natural.

I also like the way warn ... and next reads, and have used it extensively. But, it is logically incorrect.

The next is not logically dependant upon the success of warn, and should not be made so.

In the unlikely event that warn failed, the next would not be actioned and the wrong action would result.

It should be -- and when I remember, I now code it as -- warn(...), next. Many people don't like the comma operator, but those same people probably wouldn't use warn and next either.

Now to why the though came up in my previous post. This:

for (1..5) {
    print if eval{
        do_foo() && do_bar()
    } or warn $@; 
}
[download]

Would be cleaner than:

for (1..5) {
    print if eval{
        do_foo() && do_bar()
    } or do{ 
        warn $@; 
        0 
    };
}
[download]

but currently would do the wrong thing.

Of course, it is too late now, but that doesn't detract from the notion that a failure return from warn is pretty useless.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Just as I finished my reply to your post, that same notion -- slightly differently formatted -- struck me too:

for (1..5) {
    eval{
        do_foo() && do_bar()
    } and print or warn $@;
}
[download]

And when I came to post that, I saw your update. T'is much cleaner.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

In the real code there's further things being done in between the do_*() calls (computations depending on the return values of the functions etc.). So I'm not sure if chaining the calls with && would make it any clearer. (I've heavily simplified the code not to distract too much from my actual question about the reasoning behind the warning.)

I just thought that putting one eval around that entire code block would save me from having to clutter up the code with multiple evals with separate identical "catch" clauses. etc., but the warning made me wonder if there's anything wrong with it...

Thanks.

Fair enough. T'was nought but a thought :)

Funnily enough, I don't get the warning on 5.10.

#! perl -slw
use strict;

sub do_foo { $_ != 3 or die "foo == 3" }
sub do_bar { $_ != 4 or die "bar == 4" }

for (1..5) {
    eval {
        next unless do_foo();
        next unless do_bar();
        #...
        1;
    } or do {
        warn $@;
        next;
    };
    print;
}

__END__
c:\test>junk47
1
2
foo == 3 at C:\test\junk47.pl line 4.
bar == 4 at C:\test\junk47.pl line 5.
5
[download]

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

"Funnily enough, I don't get the warning on 5.10."

I think the next has to actually "execute" to generate the warning. In your modified version, the functions die instead of returning false (only the latter would trigger the execution of the next).

I do get the warning with all versions I've tested (5.10.0, 5.10.1, 5.12.3, 5.14.1).