31

I've noticed that Exception.pm and Error.pm don't seem to be extensively used in the Perl community. Is that due to the large footprint of eval for exception handling?

Also Perl programs appear to have a much more lenient policy regarding exception handling in general. Is there a compelling reason for this?

In any event what would be the best method for exception handling in Perl?

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
ennuikiller
  • 46,381
  • 14
  • 112
  • 137
  • 2
    dupe of http://stackoverflow.com/questions/503189/is-object-oriented-exception-handling-in-perl-worth-it http://stackoverflow.com/questions/2165161/whats-broken-about-exceptions-in-perl http://stackoverflow.com/questions/2439966/do-you-use-an-exception-class-in-your-perl-programs-why-or-why-not http://stackoverflow.com/questions/1426501/how-do-i-handle-exceptions-in-a-procedural-language -- do we really need another post about Perl exception handling? – Ether Oct 23 '10 at 22:19
  • 1
    See my answer in [Is Try::Tiny still recommended for exception handling in Perl 5.14 or later?](http://stackoverflow.com/a/10374265/2766176) – brian d foy Dec 20 '14 at 07:19

3 Answers3

58

The consensus of the Perl community seems to be that Try::Tiny is the preferred way of doing exception handling. The "lenient policy" you refer to is probably due to a combination of:

  • Perl not being a fully object-oriented language. (e.g. in contrast to Java where you can't avoid dealing with exceptions.)
  • The background of many Perl developers. (Languages like C1 and shell don't have exception mechanisms.)
  • The kind of tasks people tend to use Perl for. (Small scripts for text munging and report generation where exception handling isn't needed.)
  • Perl not having a (good) built-in exception mechanism.

Note that the last item means that you'll see a lot of code like this:

eval { something() };
if ($@) {
    warn "Oh no! [$@]\n";
}

That's exception handling even though it doesn't use try/catch syntax. It's fragile, though, and will break in a number of subtle edge cases that most people don't think about. Try::Tiny and the other exception handling modules on CPAN were written to make it easier to get right.

1. C does have setjmp() and longjmp(), which can be used for a very crude form of exception handling.

Community
  • 1
  • 1
Michael Carman
  • 30,628
  • 10
  • 74
  • 122
  • 16
    And just to clear up a common misconception which the original poster might or might not suffer from: `eval BLOCK` is *not* `eval STRING` and doesn't compile code at runtime. It's just an exception-handling method -- `try` with a funny name and slightly funny semantics. – hobbs Oct 24 '10 at 03:12
  • 1
    If we consider `setjmp`+`longjmp` an exception handling mechanism in C (however crude), then shell also has one: `trap`+`kill` (although it seems even cruder). – Ruslan Apr 08 '19 at 09:52
  • 1
    For your information, there is now a full try-catch implementation in perl with the module [Nice::Try](https://metacpan.org/pod/Nice::Try) – Jacques Jun 18 '21 at 06:31
8

Never test $@ as is, because it is a global variable, so even the test itself can change it.

General eval-template:

my $result;

eval {
    $result= something();
    # ...
    1;  # ok
} or do {
    my $eval_error= $@ || "error";
    # ...
    die $eval_error;
};  # needs a semicolon

In practice that is the lightest way. It still leaves a tiny room for funny $@ behaviour, but nothing that really concerned me enough.

2

As it has been mentioned you can use the traditional way with eval, but if you want to use more elaborate exception trapping, including with exception objects, then I recommend using the try-catch-finally blocks. There are quite a few perl modules that provide it such as Nice::Try and Syntax::Keyword::Try, but Syntax::Keyword::Try does not provide exception variable assignment or exception class catch like

  try
  {
    # something
  }
  catch( Exception $e )
  {
    # catch this in $e
  }

Full disclosure: I am the developer of Nice::Try

Jacques
  • 991
  • 1
  • 12
  • 15