77

The consensus of the Perl community seems to be that Try::Tiny is the preferred way to handle exceptions.

Perl 5.14 (which is the version I use) seems to solve the issues with eval that Try::Tiny addresses. Will Try::Tiny still provide any benefits for me?

G. Cito
  • 6,210
  • 3
  • 29
  • 42
Eugene Yarmash
  • 142,882
  • 41
  • 325
  • 378

6 Answers6

34

My answer is unpopular, but I don't think Perl programmers should be trying to use the exceedingly poor notion of the thing we call "exceptions" in Perl. These are essentially a side channel return value. However, still being enamored with the idea of exceptions, even with all the complexities of using a global variable to pass around state, people keep trying to make it work.

Practically, however, people use die to signal failure. Some will say that you can die with a reference and pass back error objects, but you don't need die for that. We have objects, so we should use all the power of objects:

 sub some_sub {
    ...
    return Result->new( error => 1, description => ... ) if $something_went_wrong;
    return Result->new( error => 0, ... );
    }

 my $result = some_sub( ... );
 if( $result->is_error ) { ... };

That doesn't involve global variables, action at a distance, scoping headaches, or require special specials. You create a tiny class Result, or whatever you want to call it, to wrap your return values so you have structured data instead of single values with no identity. There's no more wondering what a return value means. Is that undef a real value or an indication of failure? Is the return value good if it's defined or if it's true? Your object can tell you these things. And, you can use the same object with die. If you're already using the object with die and using it as the return value, there's very little to recommend all the extra stuff you have to do to tolerate $@.

I talk more about this in "Return error objects instead of throwing exceptions"

However, I know that you can't help what other people do, so you still have to pretend Perl has exceptions.

brian d foy
  • 129,424
  • 31
  • 207
  • 592
  • 2
    I agree, but as you said at the end, there are modules that `die` when they shouldn't, so we still need to know which mechanism to trap those exceptions. Future module designers, consider this approach! – Joel Berger Apr 29 '12 at 22:18
  • 6
    Very good solution, but die/exception has one big advantage: propagation through sub calls stack. I mean: do not test for pass or fail of some subroutine call - just don't catch an exception. It will propagate up, until someone catch it. – msztolcman Apr 29 '12 at 22:29
  • 2
    That propagation stuff is a very poor way to design a program. What are those higher levels supposed to do to handle an error? In Perl, you can't handle it and pick up where you left off, so you're not really handling it at all. The method I show can propagate just as well. Each level can add to the result it gets and passes on. – brian d foy Apr 30 '12 at 00:29
  • 8
    Very poor? I don't think so. Errors should be handled there, where we can say what to do with them. Many of errors shouldn't be handled - just logged, and show some message to user (this must be in GUI, not in lowest level functions). It is just design assumption, and have some pros and cons (like always). – msztolcman Apr 30 '12 at 07:02
  • Nothing you are saying necessitates "exceptions", but that by defending "exceptions" in Perl, note everything you have to accept and live with. Accepting all that is a pretty poor way to start. – brian d foy Apr 30 '12 at 14:10
  • 6
    I can understand why you make your arguments, but it requires that a programmer *never* forget to check for errors. We know they should, but what we should do in theory and what we do in practice when under the gun of a tight deadline aren't the same thing. Thus, we could forget to check for that *one* critical error and have our code continue on, blithely unaware that it's corrupting its data everywhere. – Ovid May 23 '12 at 08:23
  • I'm not saying not to check for errors. You can just as easily use "exceptions", not check the result, and let the program continue. – brian d foy Jun 17 '12 at 19:57
  • 1
    @briandfoy If you choose to trap and ignore an exception, you have to write explicit code to do that, which is good because you rarely want to do that. Overwhelmingly you want something to be done with an error, even just the default to crash the program with a message, so that should be the default. Having to check for a returned error and die every single time inverts this, the default is to do the rare thing, ignore the error. If you forget and slip up... it's silent. If you find code that doesn't check for a return error, did they mean to do that, or did they forget? Who knows? – Schwern Dec 18 '14 at 08:36
  • You don't have to write code to ignore an exception. There's nothing extra required for that. But, consider the converse. Did you check that everything worked? I don't find it all that bad and it's what Mojo does, among many others. – brian d foy Dec 18 '14 at 15:12
31

It was always a case of personal preference. Do you prefer

my $rv;
if (!eval { $rv = f(); 1 } ) {
   ...
}

or

my $rv = try {
   f();
} catch {
   ...
};

But keep in mind the latter uses anon subs, so it messes with return, as well as next and the like. Try::Tiny's try-catch might well end up far more complicated as you add communication channels between the catch block and outside of it.

The best case (simplest) scenario for returning on exception is if $rv is always true when there is no exception. It would look like the following:

my $rv;
if ($rv = eval { f() }) {
   ...
   return;
}

vs

my $rv = try {
   f();
} catch {
   ...
};

if (!$rv) {
   return;
}

That's why I would use TryCatch instead of Try::Tiny were I to use such a module.

The change to Perl simply means that you can do if ($@) again. In other words,

my $rv;
if (!eval { $rv = f(); 1 } ) {
   ...
}

can be written

my $rv = eval { f() };
if ($@) {
   ...
}
ikegami
  • 367,544
  • 15
  • 269
  • 518
  • 4
    If you don't need to catch the value returned by the eval (which for me at least is the most common case) - then the eval version becomes quite a bit simpler. – zby Apr 28 '12 at 19:58
  • TryCatch has far fewer caveats than Try::Tiny, and it is much faster. There is one caveat, it is abominably slow to load. – Schwern Dec 18 '14 at 08:45
  • 1
    @Schwern, A solution based on Devel::CallParser should load faster. – ikegami Dec 18 '14 at 12:49
  • 1
    @ikegami No, the problem is its reliance on Moose and Parse::Method::Signatures (the guts of MooseX::Method::Signatures). – Schwern Dec 18 '14 at 18:49
  • 1
    @Schwen, That's why Devel::CallParser would help. It would allow you to use `perl`'s builtin parsing functions. – ikegami Dec 18 '14 at 19:11
  • [Devel::Declare](https://metacpan.org/pod/Devel::Declare) (on which [TryCatch](https://metacpan.org/pod/TryCatch) is based) is [deprecated](https://metacpan.org/pod/MooseX::Declare#WARNING). Since the advent of the [Keyword API](http://perldoc.perl.org/perlapi.html#PL_keyword_plugin) in Perl 5.14 and the seemingly more stable [Devel::CallParser](https://metacpan.org/pod/Devel::CallParser), other, from my experience more robust, alternatives have emerged: [Syntax::Feature::Try](https://metacpan.org/pod/Syntax::Feature::Try) and [Try](https://metacpan.org/pod/Try). – Patrick Böker Oct 14 '15 at 08:46
  • @patszim, Devel::Declare is not deprecated. It's not perfect, sure, but that doesn't make it deprecated. Your alternatives aren't much better. Keyword API is "broken by design". Devel::CallParser has issues as well: Backwards compatibility, portability issues (didn't work on Windows, but might now), bad error messages on syntax errors. (I think I was the first to release modules using D::CP: Syntax::Feature::Loop and Syntax::Feature::QwComments). – ikegami Oct 14 '15 at 15:33
14

If nothing else, Try::Tiny is still nice syntactic sugar. If you want something a little more heavyweight, there's also TryCatch, which solves some issues related to the fact that the clauses in Try::Tiny are subroutines (for instance, that return doesn't leave the enclosing function).

11

Try::Tiny is easy and lightweight. Too easy. We had two problems:

  • anonymous subs - there was always problems with 'return' statement inside
  • catching always and everything

So I did some changes to Try::Tiny, that helps us. Now we have:

try sub {},
catch 'SomeException' => sub {},
catch [qw/Exception1 Exception2/] => sub {},
catch_all sub {};

I know - this syntax is a little exotic, but thanks to evident 'sub', our programmers now know that 'return' statement exits just from exception handler, and we always catch only this exceptions that we want to catch :)

msztolcman
  • 397
  • 3
  • 10
  • 1
    Note that you could have used `sub{}` without any change to Try::Tiny: `perl -MTry::Tiny -E"&try(sub { say 'A'; die qq{B\n} if $ARGV[0] }, &catch(sub { print; }));" 1` – ikegami Apr 28 '12 at 20:36
  • 3
    But more importantly, note that other modules (e.g. [TryCatch](http://search.cpan.org/perldoc?TryCatch)) use real blocks, not anon subs, avoiding the noise. – ikegami Apr 28 '12 at 20:38
  • 1
    There's no way to *not* catch everything in Perl, unless you write code that re-throws exceptions that aren't recognized :) – hobbs Apr 29 '12 at 02:09
  • @ikegami: yes, I can, but it's easy to forget it, if syntax doesn't require it. TryCatch of course have better solutions, but `Try::Tiny` with my modifications is lightest I think :) – msztolcman Apr 29 '12 at 07:58
  • 2
    @hobbs: of course :) but if rethrow is made without your participation in it... it's much better ;) The most important thing here is different keyword for catching all exceptions then for catching just few of them :) – msztolcman Apr 29 '12 at 08:01
  • 3
    Depends on what you mean by light. In terms of CPU, Try::Tiny loses heavily. On the other hand, TryCatch has more complex dependencies. – ikegami Apr 29 '12 at 08:16
1

Try::Tiny is great, but requires semi colon on the last brace and does not permit the use of exception variable assignment and let alone the catching of exception class. TryCatch used to do a great job, but has been broken with the new version 0.006020 of Devel::Declare. Another great implementation is Syntax::Keyword::Try but it does not implement exception variable assignments or catching exception class.

There is a new module Nice::Try, which is a perfect replacement.

There is no need to have semi colon on the last brace like Try::Tiny.

You can also do exception variable assignment like

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

It also works using class exception like

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

And it also supports finally. Its features set make it quite unique.

Full disclosure: I have developed this module when TryCatch got broken.

Jacques
  • 991
  • 1
  • 12
  • 15
0

Either do:

local $@;
eval { … }

… to prevent changes to $@ from affecting global scope, or use Try::Tiny.

Syntactically, there are situations where I prefer one or the other.