Maybe this is clearer?

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

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

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

I would be interested to read you expound upon this aside. I can think of no circumstance where the actual return value of die is relevant. 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.

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?

Looks like you can't put "next" inside an "eval". You can try to refactor the code and put the checking of the return value of the "sub" outside the eval block, e.g.:

#!/usr/bin/perl -lw
use strict;
use diagnostics;

sub do_foo { die "err" if $_==2;  $_!=4 }
sub do_bar { "..."; }

for (1..5) {
    my $flag = 1;
    eval {
        $flag &&= do_foo();
        $flag &&= do_bar();
    };
    if ($@) {
        warn $@;
        next;
    }
    next if (!$flag);
    print;
}
[download]

Just realized that my solution is different with what you want. In mine, it will still execute do_bar, eventhough do_foo returns false. The only way that I can think to break from eval is to raise an exeception, e.g.:

#!/usr/bin/perl -lw
use strict;
use diagnostics;

sub do_foo { die "err" if $_==2;  $_!=4 }
sub do_bar { "..."; }

for (1..5) {
    eval {
        die 'next please' unless do_foo();
        die 'next please' unless do_bar();
    };
    if (my $e = $@) {
        warn $e if ($e !~ /^next please/);
        next;
    }
    print;
}
[download]

Hope this is what you are looking for

Thanks for your thoughts.

Actually, your first suggestion was fine, and it looks like a reasonably elegant alternative to using next. Due to short-circuit evaluation, subsequent functions do in fact not execute, once the flag has become false:

sub do_foo { print "running foo"; die "err" if $_==2;  $_!=4 }
sub do_bar { print "running bar"; "..."; }

for (1..5) {
    print "-----";
    my $ok = 1;
    eval {
        $ok &&= do_foo();
        $ok &&= do_bar();
    };
    if ($@) {
        warn $@;
        next;
    }
    next unless $ok;
    print;        
}

__END__
-----
running foo
running bar
1
-----
running foo
err at ./test.pl line 5.

-----
running foo
running bar
3
-----
running foo
-----
running foo
running bar
5
[download]

Still, I'm not sure what's wrong with using next from within eval. I mean, you don't generate warnings without a good reason...

Of course there are plenty of reasons why you might want to know what die, or its equivalent, said.   I routinely use packages such as Exception::Class and Try::Tiny to go very considerably beyond that.   I, too, have noticed that certain constructs don’t work within an eval{} and simply code around it and move on.