Error Handling (eval & die)

Introduction

Real programs fail: files go missing, network calls time out, users type nonsense into a form. Perl gives you two simple building blocks for dealing with this gracefully - die to raise an error, and eval to catch it. Together they form Perl's version of exception handling, and they show up constantly in production scripts.

Why Error Handling Matters

Without any error handling, a single failed file open or a division by zero will kill your entire script - even if the failure only affects one record out of ten thousand. Proper error handling lets you decide what "failure" means for your program: log it and continue, retry, clean up a partially-written file, or report a friendly message instead of a raw Perl crash dump.

The die Function

die raises a fatal error. If nothing catches it, the program prints the message to STDERR and exits with a non-zero status. die takes a string message; if that message does not end in a newline, Perl helpfully appends " at SCRIPT line N." so you can find where the error came from. If you end your message with a newline yourself, that suffix is suppressed - useful when you are writing a clean, user-facing error message.

use strict;
use warnings;

my $age = -5;
die "Age cannot be negative: $age\n" if $age < 0;

print "Age is valid.\n";

Catching Errors with eval

Wrapping code in eval { ... } runs it in a protected context. If anything inside the block dies, Perl does not crash the whole program - instead, eval returns undef, execution continues right after the block, and the error message is stored in the special variable $@.

use strict;
use warnings;

sub divide {
    my ($a, $b) = @_;
    die "Cannot divide by zero\n" if $b == 0;
    return $a / $b;
}

my $result = eval { divide(10, 0) };
if ($@) {
    print "Caught an error: $@";
} else {
    print "Result: $result\n";
}

Checking $@ After eval

$@ holds the error from the most recent eval. It is set to an empty string if the eval succeeded, and to the die message (or object) if it failed. Because $@ can be overwritten by the very next statement that runs another eval, always check it immediately - and consider copying it into a lexical variable right away.

use strict;
use warnings;

eval {
    open(my $fh, '<', 'missing_file.txt') or die "open failed: $!\n";
};
if (my $err = $@) {
    print "Error occurred: $err";
}
print "Program continues...\n";

eval BLOCK vs eval STRING

eval { ... } (a block) is compiled once, at compile time, just like normal code - this is what you should use almost always. eval "string" (a string) is compiled at runtime from a string you build yourself. It works, but it is slower, harder to debug, and risky if the string ever contains untrusted input, since it will happily execute arbitrary Perl code.

use strict;
use warnings;

my $code   = '2 + 2';
my $result = eval $code;
print "Result: $result\n";

Structured Error Objects

die does not require a plain string - you can die with a reference, including a blessed object. This lets larger applications carry structured information (an error code, a category, extra data) instead of just a sentence, which is much easier for calling code to act on programmatically.

use strict;
use warnings;

package MyError;
sub new {
    my ($class, %args) = @_;
    return bless { message => $args{message}, code => $args{code} }, $class;
}
sub message { return $_[0]->{message} }
sub code    { return $_[0]->{code} }

package main;

eval {
    die MyError->new(message => 'User not found', code => 404);
};

if (my $err = $@) {
    if (ref($err) && $err->isa('MyError')) {
        printf "Error %d: %s\n", $err->code, $err->message;
    } else {
        print "Unexpected error: $err";
    }
}

Perl vs Exceptions in Other Languages

If you know try/catch from Java, JavaScript, or Python, die/eval will feel familiar: die is like throw, and eval is like try. The historical difference is syntax - Perl bolted this onto an existing function-and-block system rather than adding new keywords. Modern Perl (5.34 and later) actually does add real try/catch syntax as an experimental feature, which reads much closer to other languages.

use strict;
use warnings;
use feature 'try';
no warnings 'experimental::try';

try {
    die "Something broke\n";
}
catch ($e) {
    print "Caught: $e";
}

Nested and Re-thrown Errors

It is common to catch a low-level error, add context, and re-throw it so a caller further up the stack knows something failed without needing to know the internal details.

use strict;
use warnings;

sub risky_operation {
    eval {
        die "low-level failure\n";
    };
    if ($@) {
        die "risky_operation failed: $@";
    }
}

eval {
    risky_operation();
};
print "Final error: $@" if $@;

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

die and eval give Perl a simple but powerful error-handling model: raise a fatal error with die, catch it safely with eval, and inspect what happened through $@. Whether you use the classic $@ idiom, Try::Tiny, or the newer native try/catch syntax, the underlying mechanism is the same. Next, you will look at how to format output cleanly with sprintf and printf.