Peter Scott wrote:
>
> Brust, Corwin wrote:
> >
> > 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.
>
> I find myself indifferent on the subject of where the exception
> stack is stored (well, at least indifferent to the choices of @_
> and @@), even given the ramifications of each. I would like to
> see each mentioned as alternatives; I don't mind which one is
> preferred.
Consider this case:
catch $@->{severity} eq "Fatal" => { ... }
Are you proposing to make @_ the exception stack in the catch
expressions too, as is:
catch $_[0]->{severity} eq "Fatal" => { ... }
How would you handle:
catch $@->isa($_[0]) => { ... }
Remember, these are expressions and blocks, *not* subs. In such
cases I excpect @_ to reflect the surrounding context, not magically
start to appear to be something different. I expect the following
to print B:
@_ = qw(A B C); try { ... } finally { print $_[1] }
Remember RFC 88 + MOTIVATION + Rule 1:
1. The ability to distinguish the normal control flow from
the exception handling flow to make the structure of the
program clear.
For many decades the telephone industry has *not* used normal phone
lines to send failure messages, because if the failure message is
that the line is down, well, you get the picture. Instead, they
have long relied on a seperate signalling channel. That's $@.
Yours, &c, Tony Olekshy
