Outside an eval
, prints the value of LIST to STDERR
and
exits with the current value of $!
(errno). If $!
is 0
,
exits with the value of ($?>> 8)
(backtick `command`
status). If ($?>> 8)
is 0
, exits with 255
. Inside
an eval(),
the error message is stuffed into $@
and the
eval
is terminated with the undefined value. This makes
die
the way to raise an exception.
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.
See also exit(), warn(), and the Carp module.
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.
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{expr} in perlvar for details on setting %SIG
entries, and
eval BLOCK 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 eval()ed 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.