Yeah, don't do that.

Well, I certainly don't. This is a contrived example of course. Such code, if present, usually is buried inside a module chain (probably of third party modules), and if so, difficult to debug.

But, yes, you lose programmatic access to inner error(s). But if you want programmatic access to errors, then you should be using structured exceptions and you get access to the inner error by having the outer exception store a reference to the inner exception.

With @@, there would be no need to store references to the inner exception, and any code that doesn't, would do.

I agree with all your points of proper error handling, and in fact I do follow them in my coding. But the code I write just makes up for 2% of the whole code perl exercises in any program or application running on my behalf.

I don't see any way for your idea of collecting all exceptions to produce more signal than noise.

This is the case also with e.g. Carp::confess and perls backtrace facility. It is in place, but you don't need it. Except when you do.

Actually, I don't even see how such an idea ever allows for an exception to be freed. So catching an exception just becomes a memory leak.

That depends on the semantics of @@. The current value of $@ could be pushed onto it, if $@ hasn't been accessed before resetting. And it could be handled via a pragma:

use evalerrorstack; # @@ initialized
...
no evalerrorstack; # @@ cleared
[download]

But you didn't get my point, which is: $@ is related to eval errors. Why isn't @@ ? Probably the answer is: you don't need it, it can be done otherwise, and there is a canonical way to handle (eval) errors.

Actually, the idea of using @@ comes from wanting to be able to say:

sub expand {
    my $macros = shift;
    my $result;
    @{$result}{keys %$macros} = map { eval $_ } values %$macros;
    return if @@;
    $result;
}
[download]

If a subroutine fails, I usually set $@ and just return. In the above case, there may be a bunch of failures which are all related to macro expansion, which I would like to be able to report. The above is for now written as

sub expand {
    my $macros = shift;
    my $result;
    my @errors;
    for ( keys %$macros ) {
        $result->{$_} = eval $macros->{$_};
        push @errors, $@ if $@;
    }
    if ( @errors ) {
        $@ = join "\n", @errors;
        return;
    }
    $result;
}
[download]

but having @@ acummulate $@ would just be handy if failures occur in list context and/or $@ hasn't been accessed before it is being set again.