I'm working on the "Error Handling and Reporting" chapter of Mastering Perl. In perlvar's entry for $@
, it says:
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?
In case anybody reads the question and still wonders (like I did) if $@
can be undefined after the eval
, I believe the answer is no. (I had also read about it being "null" in old 5.8.3 docs for $@, and I was confused because "null" isn't a term often used in Perl.)
I don't have knowledge of the Perl internals to confirm this, but it looks like the docs were eventually fixed in 2015 with this commit, which came about due to this issue. perlvar's entry now says "empty string" instead of "null":
The Perl error from the last "eval" operator, i.e. the last exception that was caught. For "eval BLOCK", this is either a runtime error message or the string or reference "die" was called with. The "eval STRING" form also catches syntax errors and other compile time exceptions.
If no error occurs, "eval" sets $@ to the empty string.
Also, given $@ can be set to the "string or reference die was called with", I thought I would make sure die undef
didn't do it. Indeed, doing that is caught and handled by Perl:
% perl -we 'eval { die undef }; print "EVAL_ERROR: $@"'
Use of uninitialized value in die at -e line 1.
EVAL_ERROR: Died at -e line 1.