Damian Conway wrote:
>
> > > I would propose that the C<grep> operation should short-circuit if the
> > > block throws an exception, with the value of the expection determining
> > > whether the final invocation of the block should accept the element it
> > > was filtering:
> >
> > Otherwise nice but until now die() has been a serious thing, now it's
> > being downgraded to "oh, well, never mind (the rest)" status...
>
> No. C<die> has for a long time now been the exception throwing mechanism
> as well. Nowadays C<die> is only "serious" if you're too lazy to catch the
> exceptions it throws.
>
> This proposal just suggests that C<grep>, C<map>, etc. should catch
> exceptions emanating from their control BLOCKs and act on them. :-)
>
> Damian
Ick.
>From the standpoint of die() being something serious and fatal unless
caught, this weakens die() considerably, because you'll need to do
another die() after the grep or map or whatever.
>From the standpoint of die() being the exception throwing mechanism,
this weakens die() considerably because lots of things can now catch
your exceptions, and if you want to be sure they get propagated all the
way up to the appropriate handler, you have to keep re-throwing the damn
things.
Both are pretty much the same. Combining them, I'd say that exceptions
should remain exceptional.
Counterproposal: grep, map, etc. define two implicit magic labels
'ACCEPT' and 'REJECT' that behave in the expected way, so you use
($first_small) = grep { ($_ < 2) and last ACCEPT } @list.
To get small numbers and primes, use
@list = grep { goto ACCEPT if isprime($_); $_ < 10 } 0..100;
or, equivalently,
@list = grep { next ACCEPT if isprime($_); $_ < 10 } 0..100;
and to produce qw(bed feed feed): (new capability)
@list = grep { /e/g and redo ACCEPT } qw(cat bed dish feed)
A bare 'last' within such a block would be, implicitly, 'last REJECT'.
Or leave it an error?
You wouldn't be able to escape the innermost enclosing grep or map with
this. I'm not sure if that's good or bad.
