RE: Exception stack: let's use the @@ list.

<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