Re^4: Try::Tiny catch block with $

That's not the main eval gotcha that Try::Tiny seeks to solve. Amongst the things mentioned in Try::Tiny's documentation are:

It is possible to throw an exception which is considered false in a boolean context, thus breaking if ($@). Try::Tiny isn't fooled by that.
If a DESTROY method calls eval then an object used within your eval could potentially clobber $@. Try::Tiny creates a copy of $@ that is safe, and passes it as a parameter to the catch block.

These errors are fairly rare in practice, but extremely difficult to figure out when they do happen. People who have been burned by them in the past tend to appreciate Try::Tiny quite a lot.

package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

Comment on Re^4: Try::Tiny catch block with $_ eq '' Select or Download Code

Replies are listed 'Best First'.
Re^5: Try::Tiny catch block with $_ eq '' by vsespb (Chaplain) on May 17, 2013 at 12:38 UTC
It is possible to throw an exception which is considered false in a boolean context Don't use `if ($@)` [download] Use `unless defined eval { somecode(); 1; }` [download] If a DESTROY method calls eval then an object used within your eval could potentially clobber $@. True, well, I count it as nesting evals. UPD: I am not trying to tell that eval is better than Try::Tiny. I just think that OP might want to temporary change one statement to see how it works with plain eval{}. For cases when people use nested exceptions try/catch blocks, heavy use Exception handling pattern, heavy use OOP (with descructors), Try::Tiny is much better than eval{} (it's impossible to work with eval actually) But there are valid cases when people don't need to use Exceptions/OOP in so heavy way. Then it's perfectly valid to simply use eval then. And learning eval gotchas is as hard as learning Try::Tiny gotchas.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Try::Tiny catch block with $_ eq ''
by vsespb (Chaplain) on May 17, 2013 at 12:38 UTC

It is possible to throw an exception which is considered false in a boolean context

if ($@)
[download]

unless defined eval { somecode(); 1; }
[download]

If a DESTROY method calls eval then an object used within your eval could potentially clobber $@.

UPD:

I am not trying to tell that eval is better than Try::Tiny. I just think that OP might want to temporary change one statement to see how it works with plain eval{}.

For cases when people use nested exceptions try/catch blocks, heavy use Exception handling pattern, heavy use OOP (with descructors), Try::Tiny is much better than eval{} (it's impossible to work with eval actually)

But there are valid cases when people don't need to use Exceptions/OOP in so heavy way. Then it's perfectly valid to simply use eval then. And learning eval gotchas is as hard as learning Try::Tiny gotchas.

[reply]
[d/l]
[select]