<insert light-bulb-over-my-head here>
I'm rejigging RFC 88 so that not only does $@ refer to the
current exception, but @@ refers to the exception stack. This
moves all the link handling stuff (such as link and any) out
of the Exception class and into the handling mechanism itself.
So, now you can say:
catch grep { $_->isa("Foo") } @@ { ... }
Perl 5 allows:
@@ = qw(A B C); print $@[1], "\n";
and prints B. Am I missing any potential problem with this?
"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; }
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.
Yours, &c, Tony Olekshy
