<snip>
-----Original Message-----
From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
So, now you can say:
catch grep { $_->isa("Foo") } @@ { ... }
</snip>
Ok, I think I could learn that.
<snip>
"Brust, Corwin" wrote:
>
> In the context of a catch block, if could @_ contain the
> exception stack, starting with the current exception, could
> C<warn> be modified to act of @_ if called in void context
> with no arguments?
>
> This might give us (from the above example:
>
> catch "FILE-NO-OPEN" { warn; next; }
>
> where the C<warn> snarfs up the @_, (ie the exception stack)
> as context for the warning.
>
> This could of course be done by passing explictly passing an
> argument (probably the current exception) to warn for
> 'stringification', but this has the advantage of seeming to
> save us
>
> my $current_exception = shift;
> catch "FILE-NO-OPEN" { warn $current_exception; next; }
Inside catch $@ is already the current exception, so you could
just say:
catch "FILE-NO-OPEN" { warn $@; next; }
On the other hand, you can already say the following, which
may be all you want here:
catch "FILE-NO-OPEN" { print $@->show; next; }
</snip>
Yeah, I see. And C<warn "$@"> is the same as C<warn $@->show> right?
<snip>
Peter Scott wrote:
>
> I like the idea of passing the exception stack in @_. If we
> use the RFC 63/Error.pm idea of passing the current exception
> in $_[0], then this falls out naturally, and no need to follow
> a linked list. Gets my vote.
Yes, but since we can't do that in catch expressions (although
we could have with the old trap { } block), we would have an
unsettling (to me) difference in the way the current exception
is handled. Also, $_[0]->foo fails to satisfy the requirement
that exception flow control should be distinguished from local
flow control, because $_[0] could be anything, whereas $@ is
always an exception, so it's clear what's going on.
@@ solves all these problems elegantly.
</snip>
Prolly does. I guess I simply disagree with the necessity of segragating
arguments to exception handling from program/subrutine arguments. I've come
to like @_ as our input list and think that exception handling blocks would
naturaly use this.
Also it seems convienent, which seems perlish.
Hmmm...
for (@plays) {
$qb->pass;
warn && next if catch 'incomplete');
goto start_possesion if catch 'interception';
resolve_fumble if catch 'fumble';
update_field_position
}
Where any exception that's not C<catch>ed is actualy a (runtime) error.
-Corwin
