Is Try::Tiny still recommended for exception handling in Perl 5.14 or later?

PerlException Handling

Perl Problem Overview


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?

Perl Solutions


Solution 1 - Perl

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.

Solution 2 - Perl

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 ($@) {
   ...
}

Solution 3 - Perl

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).

Solution 4 - Perl

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 :)

Solution 5 - Perl

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.

Solution 6 - Perl

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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionEugene YarmashView Question on Stackoverflow
Solution 1 - Perlbrian d foyView Answer on Stackoverflow
Solution 2 - PerlikegamiView Answer on Stackoverflow
Solution 3 - Perluser149341View Answer on Stackoverflow
Solution 4 - PerlmsztolcmanView Answer on Stackoverflow
Solution 5 - PerlJacquesView Answer on Stackoverflow
Solution 6 - PerlPeregrineYankeeView Answer on Stackoverflow