die raises an exception. Inside an
eval the error message is stuffed into
$@ and the eval is terminated with the
undefined value. If the exception is outside of all enclosing
evals, then the uncaught exception prints LIST to
STDERR
and exits with a non-zero value. If you need to exit the
process with a specific exit code, see exit.
Equivalent examples:
If the last element of LIST does not end in a newline, the current script line number and input line number (if any) are also printed, and a newline is supplied. Note that the "input line number" (also known as "chunk") is subject to whatever notion of "line" happens to be currently in effect, and is also available as the special variable $. . See $/ in perlvar and $. in perlvar.
Hint: sometimes appending ", stopped"
to your message will cause it
to make better sense when the string "at foo line 123"
is appended.
Suppose you are running script "canasta".
produce, respectively
- /etc/games is no good at canasta line 123.
- /etc/games is no good, stopped at canasta line 123.
If the output is empty and $@ already contains a value
(typically from a previous eval) that value is reused after
appending "\t...propagated"
. This is useful for propagating exceptions:
If the output is empty and $@ contains an object
reference that has a PROPAGATE
method, that method will be called
with additional file and line number parameters. The return value
replaces the value in $@ ; i.e., as if
$@ = eval { $@->PROPAGATE(__FILE__, __LINE__) };
were called.
If $@ is empty, then the string "Died"
is used.
If an uncaught exception results in interpreter exit, the exit code is determined from the values of $! and $? with this pseudocode:
As with exit, $? is set prior to
unwinding the call stack; any DESTROY
or END
handlers can then
alter this value, and thus Perl's exit code.
The intent is to squeeze as much possible information about the likely cause
into the limited space of the system exit code. However, as
$! is the value of C's errno
, which can be set by
any system call, this means that the value of the exit code used by
die can be non-predictable, so should not be relied
upon, other than to be non-zero.
You can also call die with a reference argument, and if this is trapped within an eval, $@ contains that reference. This permits more elaborate exception handling using objects that maintain arbitrary state about the exception. Such a scheme is sometimes preferable to matching particular string values of $@ with regular expressions. Because $@ is a global variable and eval may be used within object implementations, be careful that analyzing the error object doesn't replace the reference in the global variable. It's easiest to make a local copy of the reference before any manipulations. Here's an example:
Because Perl stringifies uncaught exception messages before display, you'll probably want to overload stringification operations on exception objects. See overload for details about that.
You can arrange for a callback to be run just before the die does its deed, by setting the $SIG{__DIE__} hook. The associated handler is called with the error text and can change the error message, if it sees fit, by calling die again. See %SIG in perlvar for details on setting %SIG entries, and eval for some examples. Although this feature was to be run only right before your program was to exit, this is not currently so: the $SIG{__DIE__} hook is currently called even inside evaled blocks/strings! If one wants the hook to do nothing in such situations, put
- die @_ if $^S;
as the first line of the handler (see $^S in perlvar). Because this promotes strange action at a distance, this counterintuitive behavior may be fixed in a future release.