New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exiting eval via last #7273
Comments
From @ysthCreated by @ysthexiting an eval BLOCK via last when there is no loop block there This is correct: $ perl -we'{eval { print "1"; last; print "2" }; print "3"} print "4";' This should print only "1" and give the: Can't "last" outside a loop block $ perl -we'eval { print "1"; last; print "2" }; print "3"' This is also correct: $ perl -we'{eval { print "1"; last; print "2" }; print "3"} print "4";' The following is just plain weird. Once it's printed "3", why is it then $ perl -we'sub foo { eval { print "1"; last; print "2" }; print "3"} foo; All behavior consistent on 5.6.2, 5.8.[1234], 5.9.[01], and bleadperl. Perl Info
|
From @ysthOn Wed, Apr 28, 2004 at 04:17:12PM -0700, sthoenna@efn.org wrote:
Err, that was supposed to be this: $ perl -we'sub foo { eval { print "1"; last; print "2" }; print "3"} { foo; } p |
From @iabynOn Wed, Apr 28, 2004 at 11:17:43PM -0000, Yitzchak Scott-Thoennes wrote:
[snip]
They both look identical to me?
The eval { } is trapping the fatal error C<Can't "last" outside a loop block> Although frankly I think that last-ing out of a sub should be a fatal $ ./perl -wle' sub f { redo if $_[0] > 2 } for (1..5) { print $_; f($_) }' ie you can control the loop that calls the sub from within the sub! -- |
The RT System itself - Status changed from 'new' to 'open' |
From @ysthOn Mon, 3 May 2004, Dave Mitchell wrote:
I posted a response with the correct second correct case; something like: printing "14"
Why is that fatal in an eval but not in a sub? (Relying on my memory here;
That's the intent; IIRC, the warning was added later when it was realized |
From @iabynOn Mon, May 03, 2004 at 08:36:05AM -0700, Yitzchak Scott-Thoennes wrote:
It's still fatal: $ ./perl -wle'sub foo { print "1"; last; print "2" } foo; print "4";'
The warning's been there since at least 5.000. There's no mention in -- |
From @ysthOn Mon, May 03, 2004 at 04:23:04PM +0100, Dave Mitchell <davem@iabyn.com> wrote:
Ok, that makes sense; I overlooked that as a possibility because of the So, the only bug here is the bogus "Exiting subroutine via last" warning. $ perl -wle'sub {sub {eval { eval { eval { last }; print "not really exiting this eval"}; print "or this one either" }; print "not really exiting this sub"}->(); print "or this one either"}->()' |
From @iabynOn Mon, May 03, 2004 at 10:35:38AM -0700, Yitzchak Scott-Thoennes wrote:
That would be quite hard to fix efficiently. The current algorithm A lot easirt approach would be to stop or die when a sub/eval context is Does anyone have any enthusiasm for any of the following (in order of 1. making 'Exiting subroutine/eval/etc via last/redo/etc' 2. making the warning mandatory 3. making it stop at the first sub/eval it finds, ie sub f { last } becomes equivalent to sub f { return } (but with 4. making it die at the first sub/eval it finds, ie upgrading the current Dave. -- |
From @davidnicolDave Mitchell wrote:
I think the system is fine the way it is. If your program has If we really must do something about this non-issue (besides use strict flow that would make (next, redo, last) in subroutines fatal. Gripes about No, I do not know how many lines the patch would touch, I -- |
From rick@bort.caOn Tue, May 04, 2004 at 06:19:06PM -0500, David Nicol wrote:
We already have this. use warnings FATAL => 'exiting'; -- |
From @hvdsDave Mitchell <davem@iabyn.com> wrote: I would say that 'exiting subroutine via <control>' is a dangerous but Eval is a different beast though - my gut shrinks far more from Even so I'm not convinced it should be changed at all. And if not, Hugo |
From @iabynOn Wed, May 05, 2004 at 12:34:14PM +0100, hv@crypt.org wrote:
Yes. eval {last} will give a warning about leaving eval via last, then similar warnings -- |
From @iabynOn Wed, May 05, 2004 at 12:34:14PM +0100, hv@crypt.org wrote:
Just so we're clear on this - the current behaviour not only causes an exit -- |
From jcromie@divsol.comDave Mitchell wrote:
sorry i havent kept up here, but could this be explicitly enabled While this magic could be great for some funky jump table constructs jimc |
From @davidnicolDave Mitchell wrote:
it seems to me that the power of this construct is similar to -- |
From @timbunceOn Fri, May 07, 2004 at 08:17:29PM +0100, Dave Mitchell wrote:
Isn't that exactly what skip() does in Test::More? SKIP: { http://search.cpan.org/~mschwern/Test-Simple-0.47/lib/Test/More.pm#Conditional_tests http://search.cpan.org/src/MSCHWERN/Test-Simple-0.47/lib/Test/More.pm sub skip { This is very widely used. Tim [who hasn't been following this thread] |
From @iabynOn Fri, May 07, 2004 at 10:39:53PM +0100, Tim Bunce wrote:
Ah, so it does. Scary! -- |
From @hvdsDave Mitchell <davem@iabyn.com> wrote: I can never entirely decide whether I'm happy about it, but it isn't As well as the SKIP functionality pointed out by Tim, note that Hugo |
From @ysthOn Sun, May 09, 2004 at 03:27:25PM -0000, Hugo van der Sanden via RT <perlbug-followup@perl.org> wrote:
It seems fairly analogous to C's longjmp()...something you don't want to |
From @TuxOn Sat 08 May 2004 00:22, Dave Mitchell <davem@iabyn.com> wrote:
But in this case it uses an explicit label. A warning might be in place if no label is passed. -- |
From @iabynOn Mon, May 10, 2004 at 08:59:44AM +0200, H.Merijn Brand wrote:
A warning is generated anyway, label or no label. -- |
From @davidnicolhv@crypt.org wrote:
There is a lot of perl6 that seems to me would make a better -- |
From @cpansproutThere is no way this behaviour is going to change now. Too much code I think the warning about exiting via last when last ends up dying I’m marking this as rejected and ‘wontfix’ unless someone convinces me |
@cpansprout - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#29238 (status was 'rejected')
Searchable as RT29238$
The text was updated successfully, but these errors were encountered: