The Basics: die and eval
Perl's original exception mechanism is 'die', which immediately unwinds the call stack and stops execution with an error message, and 'eval { ... }', which catches any 'die' that occurs inside its block and stores the error text in the special variable '$@' instead of letting the program crash. A bare 'die "Connection failed\n";' produces a plain string in $@, while 'die { code => 500, message => "Connection failed" };' can pass a reference (even a blessed object) as the exception payload, letting calling code inspect structured error data rather than parsing a string. Critically, you must check '$@' immediately after the eval block, because a subsequent operation (even something like calling another eval) can overwrite it before you read it.
Cricket analogy: A third umpire's review process stops play immediately when a decision is challenged (like 'die') and the outcome gets recorded on the review screen (like $@) for the on-field umpire to check right away before the next ball resets it.
eval {
open my $fh, '<', 'missing_file.txt'
or die "Cannot open file: $!\n";
# ... more risky work ...
1; # ensure a true value on success
} or do {
my $error = $@;
warn "Caught an error: $error";
# handle or rethrow
};
# Modern equivalent (Perl 5.34+, no experimental warning needed since 5.36)
use feature 'try';
no warnings 'experimental::try';
try {
open my $fh, '<', 'missing_file.txt'
or die "Cannot open file: $!\n";
}
catch ($e) {
warn "Caught an error: $e";
}
finally {
print "Cleanup always runs here\n";
}The Modern try/catch/finally Feature
Since Perl 5.34 (stabilized without an experimental warning in 5.36), the core 'feature "try"' pragma provides native 'try { } catch ($e) { }' syntax that reads much closer to exception handling in languages like Python or JavaScript, with an optional 'finally { }' block guaranteed to run whether or not an exception occurred, useful for closing file handles or releasing locks. Unlike bare eval/$@, the caught exception is automatically scoped to the '$e' variable named in the catch clause rather than relying on the global '$@', which avoids the classic bug where a nested eval silently clobbers an outer $@ before you read it. As of 2026 this native syntax is considered stable and is the recommended default for new code on Perl 5.36+, while Try::Tiny remains common in codebases that must support older Perl versions.
Cricket analogy: DRS (Decision Review System) giving a dedicated, isolated replay screen for each specific review rather than one shared monitor everyone might overwrite mirrors 'catch ($e)' scoping the error to its own lexical variable instead of the shared global $@.
Object-Oriented Exceptions
Passing a plain string to 'die' is fine for quick scripts, but production code benefits from throwing blessed exception objects because callers can then use 'ref($e)' or 'isa()' to programmatically distinguish an out-of-stock error from a payment-declined error, rather than pattern-matching an error string with a fragile regex. Frameworks like Throwable::Error, Exception::Class, or a hand-rolled Moose/Moo class with attributes for 'message', 'code', and 'retryable' let calling code write 'catch ($e) { if ($e->isa("MyApp::Exception::NotFound")) { ... } elsif ($e->isa("MyApp::Exception::Timeout")) { ... } }', producing exception handling that mirrors the typed exception hierarchies familiar from Java or Python. This also composes cleanly with 'finally' blocks and rethrowing: 'catch ($e) { $e->isa("Retryable") ? retry() : die $e; }' propagates the original object upward instead of losing type information by stringifying it.
Cricket analogy: An umpire distinguishing between a 'no-ball' signal and a 'wide' signal using distinct, unmistakable hand gestures rather than a vague shout mirrors distinguishing MyApp::Exception::NotFound from MyApp::Exception::Timeout via isa() instead of parsing an error string.
Since Perl 5.34, 'die' without a trailing newline automatically appends the file name and line number to the error message (e.g. 'Connection failed at db.pl line 42.'); adding your own trailing "\n" suppresses that suffix, which is why library code that wants clean, predictable error text always ends its die messages with "\n".
An 'eval { }' block without a final truthy statement can silently report success even when the block's last expression evaluates to false without dying — always end risky eval blocks with an explicit '1;' as the last statement, or check $@ rather than relying solely on the block's return value, to avoid mistaking a falsy-but-non-dying result for an error or vice versa.
- 'die' halts execution and unwinds the stack; 'eval { }' catches it and stores the error in $@.
- die can throw a plain string or a reference/blessed object, enabling structured error data.
- $@ must be read immediately after eval, since a later operation can silently overwrite it.
- Native 'try { } catch ($e) { } finally { }' (stable since Perl 5.36) scopes errors to $e, avoiding $@ clobbering.
- Blessed exception objects (via Exception::Class, Throwable::Error, or Moose/Moo) let callers dispatch with isa() instead of parsing strings.
- Ending a die message with "\n" suppresses Perl's automatic 'at FILE line N' suffix.
- Always end an eval block with a truthy final statement (like '1;') to avoid conflating a falsy result with a real error.
Practice what you learned
1. What does the special variable $@ contain immediately after an eval block?
2. What advantage does the native try/catch feature (stable since Perl 5.36) have over bare eval/$@?
3. Why would you die with a blessed object instead of a plain string?
4. What happens if a die message does not end with a trailing newline?
5. What does the 'finally' block in Perl's native try/catch feature guarantee?
Was this page helpful?
You May Also Like
Object-Oriented Perl
Learn how Perl implements classes, objects, and inheritance using packages, blessed references, and the arrow operator, plus the modern Moose/Moo/class approach.
Writing Your Own Module
Build, structure, document, test, and package a distributable Perl module from scratch, from the initial .pm file to a CPAN-ready distribution.
Packages and Namespaces
Understand how Perl's 'package' keyword partitions global symbol tables to avoid naming collisions and how namespaces underpin every module and class.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics