Front page | perl.perl5.porters |
Postings from January 2022
consider
use strict;
use warnings; ### get "exiting subroutine via ..." warnings
my $rflag;
print "checkpoint A\n";
for my $i (1 .. 5){
print "i is $i\n";
$i == 1 and next;
$rflag++ or redo;
$i == 3 and last;
}
print "checkpoint B\n";
sub mynext { print "checkpoint BN\n";next }
sub myredo { print "checkpoint BR\n";redo }
sub mylast { print "checkpoint BL\n";last }
my $rflag2;
for my $i (1 .. 5){
print "i is $i\n";
$i == 1 and mynext;
$rflag2++ or myredo;
$i == 3 and mylast;
}
print "checkpoint C\n";
__END__
i therefore expect next, redo, or last in a defer block to next, last, or
redo the calling loop if any -- but at the end of the block with the defer
in it, if we ever get there.
On Fri, Jan 21, 2022 at 11:18 AM Paul "LeoNerd" Evans <
leonerd@leonerd.org.uk> wrote:
> On Wed, 19 Jan 2022 13:46:58 -0600
> David Nicol <davidnicol@gmail.com> wrote:
>
> > My expectations of what next/last/redo would do in a finally block
> > are as follows:
> >
> >
> > - last jumps to the end of the finally block
>
> `last` doesn't jump out of an if, else, try, catch, or defer block. Why
> should `finally` be any different?
>
> > - redo starts the finally block over (not the exception handler,
> > but you should be able to get there with goto label)
>
> Same question as above.
>
> > - next jumps to the test for the outer interator, if any, as if it
> > was stated outside of the construct. Why is next even an issue in
> > try/catch/finally? it isn't an interator.
>
> `next` is only a problem for the same reason that any of the loopex,
> goto or return are a problem. They're a problem because they cause a
> control flow jump directly out of the block.
>
> This is a problem for two reasons:
>
> 1) Annoying "this is hard to implement" reasons.
>
> 2) Fundamental semantic "this is meaningless" reasons.
>
> Consider
>
> sub f {
> defer { return 123; }
> die "Ooops\n";
> }
>
> What should be the result of calling f()? Once the `die` line is hit,
> we're committed to throwing an exception. The defer block gets invoked
> as part of scope unwind, but should it be permitted to `return`? Does
> it cause the call to f() to return that value and stop the exception
> propagating? In effect we've now cancelled the exception.
>
> This isn't the way that defer- or finally-alike constructions work in
> basically any other language. It would be a bad model for us to follow.
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>
--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash
Thread Previous
|
Thread Next