There's the perl special variable $@ which is set at eval errors. It is a global variable, and it is a SCALAR type variable. It gets easily clobbered if you don't proceed with utmost care (tye wrote some nodes about that) and fails to report the really interesting thing, e.g. in nested evals. Consider:

my $foo = eval {
    my $bar = baz();
    if ($@) {
        die "baz failed!\n";
    }
};
die $@ if $@;

sub baz {
    eval "1 = 2";
}
__END__
baz failed!
[download]

With that code, there's currently no way to get at the real problem, which is in the baz code, where $@ is set to

Can't modify constant item in scalar assignment at (eval 1) line 1, at
+ EOF
[download]

and gets clobbered by my $foo = eval {...} Of course, the above program would have reported the baz() error, if baz()behaved well:

sub baz {
    my $result = eval "1 = 2";
    die $@ if $@;
    $result;
}
[download]

Nonsensical assignment reported, but where is the error from my $foo = eval { };? Looks like I have to set up a die signal handler, or some such. This is all very confusing and doesn't DWIM.

And you cannot rely on $@ being propagated properly, unless you revise any included code that uses eval, which is pretty much anything, because eval is the heart of any perl code. All perl code is somehow evaled.

Back to $@ - a SCALAR. Why don't we have @@ as an error stack, and a builtin %@ hash keyed upon the names of the stack frames (e.g. Package::sub or 'eva123') or such?

The variables @@ and %@ currently (well, I have perl v5.18.2) work as a regular array/hash. But *@{SCALAR} isn't related to $@ at all.

Comments?