The Perl syntax error message from the last eval() operator. If $@ is the null string, the last eval() parsed and executed correctly (although the operations you invoked may have failed in the normal fashion).

Now I'm wondering when an eval might not execute correctly, leaving $@ with an undefined value. Are there any such cases?

This returns a null string: perl -MData::Dumper -e'$@=123; eval q{$@=456}; print(Dumper($@));' But the description is not correct. $@ is set to the argument of die if it is executed. Otherwise, it's a null string.
–
shawnhcoreyJul 21 '13 at 21:50

3 Answers
3

"The last eval() parsed and executed correctly" doesn't make any sense: eval isn't parsed at runtime. Surely, it means "the last eval() whose expression was parsed and executed correctly". In other words, "the last eval() whose expression compiled and didn't throw any exceptions when executed".

I said something about $@ being undef. Your examples are all evaluating correctly, I think, and catching errors, like they should. My question is if there will ever be a situation where it doesn't execute correctly. If not, as you suggest, I think the docs need an update so it doesn't imply some other situation that might exist (i.e. where it isn't parsed and executed correctly).
–
brian d foyJul 22 '13 at 3:26

There is a situation where it isn't parsed and executed correctly. In that situation, $@ contains the error message. I gave an example of it not parsed correctly, and and example of it not executed correctly. As I've explained, "it" can only refer to eval's operand.
–
ikegamiJul 22 '13 at 3:28

I re-entered my comment since I wanted to edit it, so your first one is actually a reply. Which one is not executed correctly? If any of them, I would have guessed the second one, but I don't think that's how I'd describe that.
–
brian d foyJul 22 '13 at 3:29

Not throwing exceptions isn't the same as failing to execute. It looks to me like #3 executes normally, doing exactly what die is supposed to do and what eval is supposed to do. The die actually runs.
–
brian d foyJul 22 '13 at 6:50

The BACKGROUND section of the Try::Tiny docs contain some info on how $@ can be clobbered and why Try::Tiny takes special care to avoid clobberage, and always tests the return value of eval rather than testing $@ for truth. All of them are in there because someone ran into them at some point, but I think that the eval-in-DESTROY scenario is the one most likely to trip someone up. Basically, if die causes some object to go out of scope, and that object has a DESTROY that calls eval, then the value that you died with to begin with is irretrievably lost. Assuming the eval in the DESTROYdoesn't throw an error, $@ will be "" following the outer eval.