"Brust, Corwin" wrote:
>
> Tony Olekshy wrote:
> >
> > Consider this case:
> >
> > catch $@->{severity} eq "Fatal" => { ... }
> >
> > Are you proposing to make @_ the exception stack in the catch
> > expressions too, as is:
>
> nope, just B<within> C<catch>.
>
> catch grep $@->isa($_), qw( list_o_classes ) # works, for me
> {
> warn; throw ; # but I like this better than
>
> warn "$@"; throw $@; # this
> }
>
> Doesn't it seems logical that the argument list would contain
> the exception stack for block defined to handle exceptions?
Perhaps, but then we have this dichotomy that it's $@ outside and
$_[0] inside. Anyway, we violate rule 1 of the MOTIVATIONS section
of RFC 88. Futhermore, this breaks my expectation on where @_
comes from, because we are in a block, not a sub.
> > 1. The ability to distinguish the normal control flow from
> > the exception handling flow to make the structure of the
> > program clear.
>
> I guess I might prefer:
>
> The ability to write exception handling code in (much) the same
> manner as code which handles normal program behavior.
No. That's just what I don't want. That's why rule 1 is in the
Encyclopaedia of Software Engineering. Down that path lies ruin.
> [...] we are introducing something new to per here. A code block
> specifically for the purpose of handling the (previously?) global
> variable formerly known as $@. IMHO it is reasonable to consider
> C<catch> a subroutine for that purpose.
>
> The disadvantage of localizing @_ for the C<catch> block seems, to
> me, outweighed by the consistency offer in keeping block input
> (clearly the exception stack, for C<catch>) in @_.
That's well and good, but the source code syntax says it's a block,
not a sub. Am I supposed to spend the rest of my life asking myself,
"Wait, is this one of Corwin's special blocks?" ;-)
I think we should leave @_ alone. @@ is free and it's the perfect
dual of $@. What more could we ask for?
Yours, &c, Tony Olekshy
