I doubt that PBP (2005) is up to date with the latest developments in this area. The recently released (2010) 2nd edition of Effective Perl Programming by brian_d_foy recommends the CPAN Try::Tiny module (released 2009) and the new core autodie pragma (added to perl 5.10.1 in 2009): see items 101 ("Use die to generate exceptions") and 103 ("Handle exceptions properly"). In particular, item 103 summarizes with "handling $@ is tricky, but Try::Tiny does it correctly". Note that Try::Tiny has zero dependencies.

2015 update: The excellent Modern Perl book by chromatic also recommends Try::Tiny; from its "Style and Efficacy" chapter, "Exception Caveats" sub-section:

Using $@ correctly requires you to navigate several subtle risks:

• Unlocalized uses further down the dynamic scope may modify $@
• It may contain an object which overrides its boolean value to return false
• A signal handler (especially the DIE signal handler) may change $@
• The destruction of an object during scope exit may call eval and change $@

use feature 'try' (2023 update: for perl 5.38+)

As clarified with a complete perl v5.38 example program, note that perl v5.34 added try/catch syntax, inspired by Syntax::Keyword::Try:

use feature 'try';
try {
   do_a_thing();
}
catch ( $e ) {
   warn "It failed - $e";
}
[download]

perl v5.36 added finally blocks to try/catch, also inspired by Syntax::Keyword::Try:

use feature 'try';
try {
   do_a_thing();
}
catch( $e ) { ... }
finally {
   cleanup();
}
[download]

Note that try-catch feature is no longer experimental with perl v5.40 - its use without a finally block no longer prints a warning but it still must be enabled with the 'try' feature. The optional finally block is still considered experimental and emits a warning, except when explicitly disabled with no warnings "experimental::try";.

Some perldoc References

• die - is how you throw exceptions in Perl
• eval - used to execute a little Perl program, trapping any errors encountered so they don't crash the calling program
• Carp - alternative warn and die for modules
• autodie - Replace functions with ones that succeed or die with lexical scope
• Fatal - Replace functions with equivalents which succeed or die

• Try Catch Exception Handling
• defer blocks
• experimental - Experimental features made easy
• feature - Perl pragma to enable new features

Exception Safety and RAII

RAII (Resource Acquisition is Initialization) is very useful when throwing exceptions in Perl (via die).

To give a very simple example, this code:

use strict;
use warnings;
sub fred {
    my $fname = 'f.tmp';
    open( FH, '<', $fname ) or die "error: open '$fname': $!";
    print "file '$fname' opened ok\n";
    # ... process file here
    die "oops";   # if something went wrong
    close(FH);
}
my $ok = eval { fred(); 1 };    # see [id://11130946]
if (!$ok) { print "died: $@\n" }
# oops, handle FH is still open if an exception was thrown.
my $line = <FH>;
print "oops, FH is still open:$line\n";
[download]

A simple remedy is to replace the ugly global FH with a lexical file handle $fh, which is auto-closed at end of scope (RAII):

use strict;
use warnings;
sub fred {
    my $fname = 'f.tmp';
    open( my $fh, '<', $fname ) or die "error: open '$fname': $!";
    print "file '$fname' opened ok\n";
    # ... process file here
    die "oops";   # if something went wrong
    close($fh);
}
my $ok = eval { fred(); 1 };    # see [id://11130946]
if (!$ok) { print "died: $@\n" }
print "ok, \$fh is auto-closed when sub fred exits (normally or via di
+e)\n";
[download]

References Added Later

Some useful recent Perl Monks nodes:

• Bug in eval in pre-5.14 by choroba (2016)
• Re: Bug in eval in pre-5.28 by haukex (2021) - later response that recommends: my $success = eval { ...; 1 };

• Should I use carp/croak or warn/die by SBECK (2018)
• Can I catch a die from someone else's module? by bartender1382 (2022) - useful replies from haukex and kcott
• canonical doc explaing need for "eval { ... } or do {...}" construct by the LanX (2022) - lots of useful recent info

• Re^7: STDERR in Test Results by afoken in response to Bod (2023) - compares Perl to C and analyses DBI RaiseError attribute and transactions
• Re^8: STDERR in Test Results by bliako in response to afoken (2023) - likes to return error codes, considering trying exceptions instead
• Re^3: SQL: Update column(s) value with extra WHERE by bliako (2023) - some discussion around the performance overhead of throwing exceptions

• Perl try { } catch(e) { } by Superfox il Volpone (2015) - trying to implement try { ... } catch { ... } without an external module
• try/finally syntax by Superfox il Volpone (2024) - trying to use the new perl v5.38 try/catch/finally syntax with perl v5.34.1

• Re^4: Schizophrenic var (semipredicate problem) by me (2023) - how functions can signal errors without using exceptions
• New built-in perl5.38 try/catch syntax by me (2023) - a complete working example program using latest perl v5.38 built-in try/catch syntax

• EyeBall stumps BodBall (Error Handling) by me (2023) - Exception Handling v Returning a value from a function indicating failure
• Re: EyeBall stumps BodBall (Error Handling) by me (2023) - ... with lots of extra references
• Re^3: EyeBall stumps BodBall by etj (2024) - mentions Devel::Confess
• Re^2: EyeBall stumps BodBall by etj (2024) - notes that GraphQL error handling always returns JSON

• Which incarnation of try/catch to use? by mldvx4 (2023)
• When to use eval by anonymonk (Feb 2024) - lots of excellent replies
• Why causes Exception::Class a fat-packed perl application to fail (but works with 5.38) by Darkwing (Jul 2024) - problem packing Exception::Class with App::FatPacker
• Nested Evals in Old Perl 5.10 by mikkoi (Aug 2024)
• Re^3: RSS Parsing not working on new machine by wintermute115 (Apr 2025)

  Some general advice from On Coding Standards and Code Reviews (API Design Checklist section):

  • Error handling. Document all errors in the user's dialect. Prefer throwing exceptions to returning special values. Prefer to find errors at compile time rather than run time.

  As noted at On Interfaces and APIs:

  • Perl 5's "string eval" and "block eval" is an example of violation of the "principle of distinction", aka "different things should look different"

  Some older nodes:

  • Best Practices for Exception Handling by Ovid (2003)
  • Intelligent Exception Handling in Perl by skynight (2003)
  • Writing Solid CPAN Modules by me (2005) - see Exception Safety section
  • Re: What is the best way to extend packages with global error handlers? by me (2009) - notes that PBP endorses Exception::Class
  • eval to replace die? by hsmyers (2010) - long thread with many heated posts from BrowserUk and responses from chromatic and mithaldu

  Some external references:

  • mod_perl (wikipedia)
  • Exception Handling for mod_perl

  CPAN Modules:

  • Try::Tiny
  • Devel::EvalError
  • Exception::Class
  • Throwable (especially with Moose or Moo)
  • Devel::Confess - include stack traces on all warnings and errors
  • Syntax::Keyword::Try by Paul Evans - a try/catch/finally syntax for perl
  • Syntax::Keyword::Defer by Paul Evans - execute code when leaving a block (via a defer block)
  • Feature::Compat::Try by Paul Evans - make try/catch/finally syntax available. On older versions of perl before such syntax is available, it is provided instead using the Syntax::Keyword::Try module.
  • Feature::Compat::Defer by Paul Evans - make defer syntax available. On older versions of perl before such syntax is available, it is provided instead using the Syntax::Keyword::Defer module.
  • Perl::MinimumVersion by Dan Book - Find a minimum required version of perl for Perl code (uses PPI)
  • Syntax::Construct by choroba - Explicitly state which non-feature constructs are used in the code

  Wikipedia:

  • Exception handling
  • RAII (Resource Acquisition is Initialization) - originated in C++
  • Dispose pattern - used in automatic garbage collection languages, such as Java and C#

  ISO C++:

  • Exceptions and Error Handling (As a rule of thumb, exception handling is extremely cheap when you don't throw an exception. It costs nothing on some implementations. All the cost is incurred when you throw an exception: that is, "normal code" is faster than code using error-return codes and tests. You incur cost only when you have an error)

  SO:

  • In what ways do c++ exceptions slow down code when there are no exceptions thrown
  • Does try catch in C++ affect performance when not hit

  See Also

  • Re: eval question (avoid string eval References)
  • Re^5: SQL: Update column(s) value with extra WHERE (Real-time Computing and Virtual Machine References)
  • Effective Automated Testing
  • Re: 5.40 released (perl new feature References)
  • Re^7: Meaning of XS object version (Package Manager Security References - example building Perl securely from source)

  Updated: added use feature 'try' and Exception Safety and RAII sections. Updated sample code based on Re: Bug in eval in pre-5.28.

I like the zero dependencies part. While poking about, I installed TryCatch and wasn't pleased with the more than 400 files that tagged along. Don't think I want to do that to folks using my module. No way to avoid some build up, but minimizing it is bound to be a good thing (™) I also read EPP 2nd and noticed the reference to use autodie; and the other modules— maybe this is the way to go. At least the Try::Tiny option; I'd just as soon avoid dragging anyone into using a more modern Perl unless I have to!

--hsm

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."

The clue to the appropriate action is in the error message:

Exception objects should be used instead of the standard Perl error mechanism.

The action is: Question.

• Say's who?
• And why?

And when no good answers are forthcoming--and they won't be--consign this "post-modern", revisionist rubbish to the bit bucket and get on with life!

... consign this "post-modern", revisionist rubbish to the bit bucket and get on with life!

Perhaps you'd be more comfortable with Tcl circa 1998.

Remember, everyone else: you don't need reliable error-handling code if you never make errors.

One big drawback of string exceptions is that you have to parse strings to decide how to handle them. Parsing strings (especially to determine flow control) is fragile.

This fragility is a small risk in smaller applications, but it's worth considering alternatives in larger applications where you must handle exceptions.

The source of errors isn't always within the script - the "open or die" idiom is used extensively in the documentation, the Camel book etc - for quick scripts, to say, parse a system file and print some useful info, this construct is perfectly suitable - exception handling etc has its place, agreed - but it's a judgement call where that place is.

Perhaps you'd be more comfortable with Tcl circa 1998.

No. I'm quite happy with Perl thank you.

You're the one who seems to want to turn Perl into Java.

One big drawback of string exceptions is that you have to parse strings to decide how to handle them. Parsing strings (especially to determine flow control) is fragile.

This is typical of your response to relatively simple problems. Throw yet another layer (or three) of complicated code on top, in an attempt to make the problems "go away".

Yes, error messages change occasionally.

Not often, but the recent addition to "Uninitialised value" is a ready exceptional hook upon which to hang your demagoguery. Despite that no one in their right mind is going to use exception handling to deal with an uninitialised variable(*). C'st la vie.

(*) Perhaps you'd offer us a worked example of how using Exception::Class to trap an uninitialised variable would have 'saved the day', when the variable name was added to the message?

We could then examine the basis of your justifictions; assess the impacts, pro's & con's of your suggested alternative; explore alternative alternatives.

Of course, you won't. Because you're a busy man with no time to explain your "wisdom", much less open it up to the challenge of open debate.

If you're performing an exact match, a substring match, or a regular expression, any change to the text of that message in a subsequent release of Perl 5 could change the way your code behaves.

So, the crux of this is that instead of the simplicity and clarity (both code and error reporting) of:

#! perl -slw
use strict;

sub divide {
    my( $e, $d ) = @_;
    return $e / $d;
}

my $result = eval{ divide( @ARGV ) } or die $@;

print "Result: $result";
[download]

<Reveal this spoiler or all spoilers in this node or all in this thread>

you're advising people to use (something like*):

(*)This doesn't actually work. Because I can't work out how to use the module. Because there are no simple, complete, working examples that I can find. Probably because it is so insanely complicated to use that simple, complete, working examples aren't possible!

#MyExceptions.pm
package MyExceptions;

use Exception::Class (
    'MyException',

    'AnotherException' => {
        isa => 'MyException'
    },

    'YetAnotherException' => {
        isa         => 'AnotherException',
        description => 'These exceptions are related to IPC'
    },

    'ExceptionWithFields' => {
        isa    => 'YetAnotherException',
        fields => [ 'grandiosity', 'quixotic' ],
        alias  => 'throw_fields',
    },
);

1;
## Exceptions.pl
#! perl -slw
use strict;
use MyExceptions;

sub divide {
    my( $e, $d ) = @_;
    MyExceptions->throw( error => 'Divisor undefined' ) unless defined
+ $d;
    MyExceptions->throw( error => 'Divisor is zero' ) if $d == 0;
    return $e / $d;
}


# try
my $result = eval { divide( @ARGV ) };

my $e;

# catch
if ( $e = Exception::Class->caught('MyException') ) {
    die 'You must supply two arguments' if $e->error eq 'Divisor undef
+ined';
    die 'The second argument must not be zero' if $e->error eq 'Diviso
+r is zero';
    die sprintf "Unanticipated exception: '%s' at \n%s\n", $e->error, 
+$e
}
else {
    $e = Exception::Class->caught();
    ref $e ? $e->rethrow : die $e;
}
[download]

If you are unable--or more likely, unwilling--to see all the ways that can go wrong. That this is even more dependant upon string comparisons. And all the addition problems you've created for the maintenance programmers to have to unwind, sift through and reverse engineer through all those extra layers, when it does go wrong. Then I guess they'll just end up reaping what you sow.

Even if you avoid comparing $e->error() to decide how to deal with the exceptions,

you are still relying upon MyException->caught( 'MyException' ),

which replies upon Exception::Class::Base->isa( 'MyException' ).

And what does isa() do that isn't subject to exactly the same error vectors a string compare?

---

There are times when exceptions are useful. But reaching for the insane complexity of modules like Exception::Class just in order to achieve "Java-esque"-ness; rather than something perlish-ly simple like Try::Tiny:

<Reveal this spoiler>

is madness. Java-envy of the worst kind.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

Well that is the alternative I mentioned towards the end of my rambling, but I really am curious as to any answers that might be out there. I realize that there are a lot of things in PBP that are questionable, same could be said of PerlTidy for that matter ;-)

--hsm

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."

I'm wondering if the following is equivalent?

Evals do not replace dies. In fact, you would use eval in combination with a die. In fact:

sub sub_that_may_die() {
    die "Oops!" if something_I_do_not_like_happens;
}
eval {sub_that_may_die()}
[download]

Ignoring the tennis match going on here, your answer of 'not equivalent' raises the obvious question of what is? I will probably upload to CPAN with the problem resolved using Try::Tiny, but I still wonder if there is a relatively simple Perl solution that just hasn't occurred to me?

--hsm

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."

If the problem is that exception objects should be used instead of die(), then Try::Tiny won't solve this at all!

Try::Tiny provides an easy-to-use alternative to eval - but without using some other module to provide exception objects, you'll still be stuck having to call die() in the catch{} block.